<!DOCTYPE HTML>
<html lang="en" class="light" dir="ltr">
    <head>
        <!-- Book generated using mdBook -->
        <meta charset="UTF-8">
        <title>Netop Document</title>
        <meta name="robots" content="noindex">


        <!-- Custom HTML head -->
        
        <meta name="description" content="">
        <meta name="viewport" content="width=device-width, initial-scale=1">
        <meta name="theme-color" content="#ffffff">

        <link rel="icon" href="favicon.svg">
        <link rel="shortcut icon" href="favicon.png">
        <link rel="stylesheet" href="css/variables.css">
        <link rel="stylesheet" href="css/general.css">
        <link rel="stylesheet" href="css/chrome.css">
        <link rel="stylesheet" href="css/print.css" media="print">

        <!-- Fonts -->
        <link rel="stylesheet" href="FontAwesome/css/font-awesome.css">
        <link rel="stylesheet" href="fonts/fonts.css">

        <!-- Highlight.js Stylesheets -->
        <link rel="stylesheet" href="highlight.css">
        <link rel="stylesheet" href="tomorrow-night.css">
        <link rel="stylesheet" href="ayu-highlight.css">

        <!-- Custom theme stylesheets -->

    </head>
    <body class="sidebar-visible no-js">
    <div id="body-container">
        <!-- Provide site root to javascript -->
        <script>
            var path_to_root = "";
            var default_theme = window.matchMedia("(prefers-color-scheme: dark)").matches ? "navy" : "light";
        </script>

        <!-- Work around some values being stored in localStorage wrapped in quotes -->
        <script>
            try {
                var theme = localStorage.getItem('mdbook-theme');
                var sidebar = localStorage.getItem('mdbook-sidebar');

                if (theme.startsWith('"') && theme.endsWith('"')) {
                    localStorage.setItem('mdbook-theme', theme.slice(1, theme.length - 1));
                }

                if (sidebar.startsWith('"') && sidebar.endsWith('"')) {
                    localStorage.setItem('mdbook-sidebar', sidebar.slice(1, sidebar.length - 1));
                }
            } catch (e) { }
        </script>

        <!-- Set the theme before any content is loaded, prevents flash -->
        <script>
            var theme;
            try { theme = localStorage.getItem('mdbook-theme'); } catch(e) { }
            if (theme === null || theme === undefined) { theme = default_theme; }
            var html = document.querySelector('html');
            html.classList.remove('light')
            html.classList.add(theme);
            var body = document.querySelector('body');
            body.classList.remove('no-js')
            body.classList.add('js');
        </script>

        <input type="checkbox" id="sidebar-toggle-anchor" class="hidden">

        <!-- Hide / unhide sidebar before it is displayed -->
        <script>
            var body = document.querySelector('body');
            var sidebar = null;
            var sidebar_toggle = document.getElementById("sidebar-toggle-anchor");
            if (document.body.clientWidth >= 1080) {
                try { sidebar = localStorage.getItem('mdbook-sidebar'); } catch(e) { }
                sidebar = sidebar || 'visible';
            } else {
                sidebar = 'hidden';
            }
            sidebar_toggle.checked = sidebar === 'visible';
            body.classList.remove('sidebar-visible');
            body.classList.add("sidebar-" + sidebar);
        </script>

        <nav id="sidebar" class="sidebar" aria-label="Table of contents">
            <div class="sidebar-scrollbox">
                <ol class="chapter"><li class="chapter-item expanded "><a href="index.html"><strong aria-hidden="true">1.</strong> 概览</a></li><li class="chapter-item expanded "><a href="addons/index.html"><strong aria-hidden="true">2.</strong> 附录</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="addons/rfc8071.html"><strong aria-hidden="true">2.1.</strong> NETCONF Call Home (RFC8071)</a></li><li class="chapter-item expanded "><a href="addons/rfc4742.html"><strong aria-hidden="true">2.2.</strong> NETCONF over SSH (RFC4742)</a></li><li class="chapter-item expanded "><a href="addons/rfc6242.html"><strong aria-hidden="true">2.3.</strong> NETCONF over SSH (RFC6242)</a></li><li class="chapter-item expanded "><a href="addons/rfc4741.html"><strong aria-hidden="true">2.4.</strong> NETCONF Protocol (RFC4741)</a></li></ol></li></ol>
            </div>
            <div id="sidebar-resize-handle" class="sidebar-resize-handle">
                <div class="sidebar-resize-indicator"></div>
            </div>
        </nav>

        <!-- Track and set sidebar scroll position -->
        <script>
            var sidebarScrollbox = document.querySelector('#sidebar .sidebar-scrollbox');
            sidebarScrollbox.addEventListener('click', function(e) {
                if (e.target.tagName === 'A') {
                    sessionStorage.setItem('sidebar-scroll', sidebarScrollbox.scrollTop);
                }
            }, { passive: true });
            var sidebarScrollTop = sessionStorage.getItem('sidebar-scroll');
            sessionStorage.removeItem('sidebar-scroll');
            if (sidebarScrollTop) {
                // preserve sidebar scroll position when navigating via links within sidebar
                sidebarScrollbox.scrollTop = sidebarScrollTop;
            } else {
                // scroll sidebar to current active section when navigating via "next/previous chapter" buttons
                var activeSection = document.querySelector('#sidebar .active');
                if (activeSection) {
                    activeSection.scrollIntoView({ block: 'center' });
                }
            }
        </script>

        <div id="page-wrapper" class="page-wrapper">

            <div class="page">
                                <div id="menu-bar-hover-placeholder"></div>
                <div id="menu-bar" class="menu-bar sticky">
                    <div class="left-buttons">
                        <label id="sidebar-toggle" class="icon-button" for="sidebar-toggle-anchor" title="Toggle Table of Contents" aria-label="Toggle Table of Contents" aria-controls="sidebar">
                            <i class="fa fa-bars"></i>
                        </label>
                        <button id="theme-toggle" class="icon-button" type="button" title="Change theme" aria-label="Change theme" aria-haspopup="true" aria-expanded="false" aria-controls="theme-list">
                            <i class="fa fa-paint-brush"></i>
                        </button>
                        <ul id="theme-list" class="theme-popup" aria-label="Themes" role="menu">
                            <li role="none"><button role="menuitem" class="theme" id="light">Light</button></li>
                            <li role="none"><button role="menuitem" class="theme" id="rust">Rust</button></li>
                            <li role="none"><button role="menuitem" class="theme" id="coal">Coal</button></li>
                            <li role="none"><button role="menuitem" class="theme" id="navy">Navy</button></li>
                            <li role="none"><button role="menuitem" class="theme" id="ayu">Ayu</button></li>
                        </ul>
                        <button id="search-toggle" class="icon-button" type="button" title="Search. (Shortkey: s)" aria-label="Toggle Searchbar" aria-expanded="false" aria-keyshortcuts="S" aria-controls="searchbar">
                            <i class="fa fa-search"></i>
                        </button>
                    </div>

                    <h1 class="menu-title">Netop Document</h1>

                    <div class="right-buttons">
                        <a href="print.html" title="Print this book" aria-label="Print this book">
                            <i id="print-button" class="fa fa-print"></i>
                        </a>

                    </div>
                </div>

                <div id="search-wrapper" class="hidden">
                    <form id="searchbar-outer" class="searchbar-outer">
                        <input type="search" id="searchbar" name="searchbar" placeholder="Search this book ..." aria-controls="searchresults-outer" aria-describedby="searchresults-header">
                    </form>
                    <div id="searchresults-outer" class="searchresults-outer hidden">
                        <div id="searchresults-header" class="searchresults-header"></div>
                        <ul id="searchresults">
                        </ul>
                    </div>
                </div>

                <!-- Apply ARIA attributes after the sidebar and the sidebar toggle button are added to the DOM -->
                <script>
                    document.getElementById('sidebar-toggle').setAttribute('aria-expanded', sidebar === 'visible');
                    document.getElementById('sidebar').setAttribute('aria-hidden', sidebar !== 'visible');
                    Array.from(document.querySelectorAll('#sidebar a')).forEach(function(link) {
                        link.setAttribute('tabIndex', sidebar === 'visible' ? 0 : -1);
                    });
                </script>

                <div id="content" class="content">
                    <main>
                        <h1 id="概览"><a class="header" href="#概览">概览</a></h1>
<h2 id="软件架构图"><a class="header" href="#软件架构图">软件架构图</a></h2>
<p><img src="./index.png" alt="&#39;arch&#39;" /></p>
<div style="break-before: page; page-break-before: always;"></div><h1 id="附录"><a class="header" href="#附录">附录</a></h1>
<div style="break-before: page; page-break-before: always;"></div><p>Internet Engineering Task Force (IETF)                         K. Watsen
Request for Comments: 8071                              Juniper Networks
Category: Standards Track                                  February 2017
ISSN: 2070-1721</p>
<pre><code>            NETCONF Call Home and RESTCONF Call Home
</code></pre>
<p>Abstract</p>
<p>This RFC presents NETCONF Call Home and RESTCONF Call Home, which
enable a NETCONF or RESTCONF server to initiate a secure connection
to a NETCONF or RESTCONF client, respectively.</p>
<p>Status of This Memo</p>
<p>This is an Internet Standards Track document.</p>
<p>This document is a product of the Internet Engineering Task Force
(IETF).  It represents the consensus of the IETF community.  It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG).  Further information on
Internet Standards is available in Section 2 of RFC 7841.</p>
<p>Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc8071.</p>
<p>Copyright Notice</p>
<p>Copyright (c) 2017 IETF Trust and the persons identified as the
document authors.  All rights reserved.</p>
<p>This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.  Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.</p>
<p>Watsen                       Standards Track                    [Page 1]

RFC 8071        NETCONF Call Home and RESTCONF Call Home   February 2017</p>
<p>Table of Contents</p>
<ol>
<li>
<p>Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   3
1.2.  Requirements Terminology  . . . . . . . . . . . . . . . .   3
1.3.  Applicability Statement . . . . . . . . . . . . . . . . .   4
1.4.  Relation to RFC 4253  . . . . . . . . . . . . . . . . . .   4
1.5.  The NETCONF/RESTCONF Convention . . . . . . . . . . . . .   4</p>
</li>
<li>
<p>Solution Overview . . . . . . . . . . . . . . . . . . . . . .   5</p>
</li>
<li>
<p>The NETCONF or RESTCONF Client  . . . . . . . . . . . . . . .   5
3.1.  Client Protocol Operation . . . . . . . . . . . . . . . .   5
3.2.  Client Configuration Data Model . . . . . . . . . . . . .   7</p>
</li>
<li>
<p>The NETCONF or RESTCONF Server  . . . . . . . . . . . . . . .   7
4.1.  Server Protocol Operation . . . . . . . . . . . . . . . .   7
4.2.  Server Configuration Data Model . . . . . . . . . . . . .   8</p>
</li>
<li>
<p>Security Considerations . . . . . . . . . . . . . . . . . . .   9</p>
</li>
<li>
<p>IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10</p>
</li>
<li>
<p>References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
7.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
7.2.  Informative References  . . . . . . . . . . . . . . . . .  12
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  13
Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13</p>
</li>
<li>
<p>Introduction</p>
</li>
</ol>
<p>This RFC presents NETCONF Call Home and RESTCONF Call Home, which
enable a NETCONF or RESTCONF server to initiate a secure connection
to a NETCONF or RESTCONF client, respectively.</p>
<p>NETCONF Call Home supports both of the secure transports used by the
Network Configuration Protocol (NETCONF) [RFC6241], Secure Shell
(SSH), and Transport Layer Security (TLS).  The NETCONF protocol's
binding to SSH is defined in [RFC6242].  The NETCONF protocol's
binding to TLS is defined in [RFC7589].</p>
<p>RESTCONF Call Home only supports TLS, the same as the RESTCONF
protocol [RFC8040].  The RESTCONF protocol's binding to TLS is
defined in [RFC8040].</p>
<p>The SSH protocol is defined in [RFC4253].  The TLS protocol is
defined in [RFC5246].  Both the SSH and TLS protocols are layered on
top of the TCP protocol, which is defined in [RFC793].</p>
<p>Both NETCONF Call Home and RESTCONF Call Home preserve all but one of
the client/server roles in their respective protocol stacks, as
compared to client-initiated NETCONF and RESTCONF connections.  The
one and only role reversal that occurs is at the TCP layer; that is,
which peer is the TCP client and which is the TCP server.</p>
<p>Watsen                       Standards Track                    [Page 2]

RFC 8071        NETCONF Call Home and RESTCONF Call Home   February 2017</p>
<p>For example, a network element is traditionally the TCP server.
However, when calling home, the network element initially assumes the
role of the TCP client.  The network element's secure transport-layer
roles (SSH server, TLS server) and its application-layer roles
(NETCONF server, RESTCONF server) all remain the same.</p>
<p>Having consistency in both the secure transport-layer (SSH, TLS) and
application-layer (NETCONF, RESTCONF) roles conveniently enables
deployed network management infrastructure to support call home also.
For instance, existing certificate chains and user authentication
mechanisms are unaffected by call home.</p>
<p>1.1.  Motivation</p>
<p>Call home is generally useful for both the initial deployment and
ongoing management of networking elements.  Here are some scenarios
enabled by call home:</p>
<p>o  The network element may proactively "call home" after being
powered on for the first time in order to register itself with its
management system.</p>
<p>o  The network element may access the network in a way that
dynamically assigns it an IP address, but does not register its
assigned IP address to a mapping service (e.g., dynamic DNS).</p>
<p>o  The network element may be deployed behind a firewall that
implements Network Address Translation (NAT) for all internal
network IP addresses.</p>
<p>o  The network element may be deployed behind a firewall that does
not allow any management access to the internal network.</p>
<p>o  The network element may be configured in "stealth mode", and thus
does not have any open ports for the management system to connect
to.</p>
<p>o  The operator may prefer to have network elements initiate
management connections, believing it is easier to secure one open
port in the data center than to have an open port on each network
element in the network.</p>
<p>1.2.  Requirements Terminology</p>
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].</p>
<p>Watsen                       Standards Track                    [Page 3]

RFC 8071        NETCONF Call Home and RESTCONF Call Home   February 2017</p>
<p>1.3.  Applicability Statement</p>
<p>The techniques described in this document are suitable for network
management scenarios such as the ones described in Section 1.1.
However, these techniques are only defined for NETCONF Call Home and
RESTCONF Call Home, as described in this document.</p>
<p>The reason for this restriction is that different protocols have
different security assumptions.  The NETCONF and RESTCONF protocols
require clients and servers to verify the identity of the other
party.  This requirement is specified for the NETCONF protocol in
Section 2.2 of [RFC6241], and is specified for the RESTCONF protocol
in Sections 2.4 and 2.5 of [RFC8040].</p>
<p>This contrasts with the base SSH and TLS protocols, which do not
require programmatic verification of the other party (Section 9.3.4
of [RFC4251], Section 4 of [RFC4252], and Section 7.3 of [RFC5246]).
In such circumstances, allowing the SSH/TLS server to contact the
SSH/TLS client would open new vulnerabilities.  Any use of call home
with SSH/TLS for purposes other than NETCONF or RESTCONF will need a
thorough contextual risk assessment.  A risk assessment for this RFC
is in the Security Considerations section (Section 5).</p>
<p>1.4.  Relation to RFC 4253</p>
<p>This document uses the SSH Transport Layer Protocol [RFC4253] with
the exception that the statement "The client initiates the
connection" made in Section 4 of RFC 4253 does not apply.  Assuming
the reference to the client means "SSH client" and the reference to
the connection means "TCP connection", this statement doesn't hold
true in call home, where the network element is the SSH server and
yet still initiates the TCP connection.  Security implications
related to this change are discussed in Section 5.</p>
<p>1.5.  The NETCONF/RESTCONF Convention</p>
<p>Throughout the remainder of this document, the term "NETCONF/
RESTCONF" is used as an abbreviation in place of the text "the
NETCONF or the RESTCONF".  The NETCONF/RESTCONF abbreviation is not
intended to require or to imply that a client or server must
implement both the NETCONF standard and the RESTCONF standard.</p>
<p>Watsen                       Standards Track                    [Page 4]

RFC 8071        NETCONF Call Home and RESTCONF Call Home   February 2017</p>
<ol start="2">
<li>Solution Overview</li>
</ol>
<p>The diagram below illustrates call home from a protocol-layering
perspective:</p>
<pre><code>      NETCONF/RESTCONF                    NETCONF/RESTCONF
           Server                              Client
             |                                    |
             |         1. TCP                     |
             |-----------------------------------&gt;|
             |                                    |
             |                                    |
             |         2. SSH/TLS                 |
             |&lt;-----------------------------------|
             |                                    |
             |                                    |
             |         3. NETCONF/RESTCONF        |
             |&lt;-----------------------------------|
             |                                    |
            Note: Arrows point from the "client" to
              the "server" at each protocol layer.

               Figure 1: Call Home Sequence Diagram
</code></pre>
<p>This diagram makes the following points:</p>
<ol>
<li>
<p>The NETCONF/RESTCONF server begins by initiating a TCP connection
to the NETCONF/RESTCONF client.</p>
</li>
<li>
<p>Using this TCP connection, the NETCONF/RESTCONF client initiates
an SSH/TLS session to the NETCONF/RESTCONF server.</p>
</li>
<li>
<p>Using this SSH/TLS session, the NETCONF/RESTCONF client initiates
a NETCONF/RESTCONF session to the NETCONF/RESTCONF server.</p>
</li>
<li>
<p>The NETCONF or RESTCONF Client</p>
</li>
</ol>
<p>The term "client" is defined in [RFC6241], Section 1.1.  In the
context of network management, the NETCONF/RESTCONF client might be a
network management system.</p>
<p>3.1.  Client Protocol Operation</p>
<p>C1  The NETCONF/RESTCONF client listens for TCP connection requests
from NETCONF/RESTCONF servers.  The client MUST support accepting
TCP connections on the IANA-assigned ports defined in Section 6,
but MAY be configured to listen to a different port.</p>
<p>Watsen                       Standards Track                    [Page 5]

RFC 8071        NETCONF Call Home and RESTCONF Call Home   February 2017</p>
<p>C2  The NETCONF/RESTCONF client accepts an incoming TCP connection
request and a TCP connection is established.</p>
<p>C3  Using this TCP connection, the NETCONF/RESTCONF client starts
either the SSH client [RFC4253] or the TLS client [RFC5246]
protocol.  For example, assuming the use of the IANA-assigned
ports, the SSH client protocol is started when the connection is
accepted on port 4334 and the TLS client protocol is started when
the connection is accepted on either port 4335 or port 4336.</p>
<p>C4  When using TLS, the NETCONF/RESTCONF client MUST advertise
"peer_allowed_to_send", as defined by [RFC6520].  This is
required so that NETCONF/RESTCONF servers can depend on it being
there for call home connections, when keep-alives are needed the
most.</p>
<p>C5  As part of establishing an SSH or TLS connection, the NETCONF/
RESTCONF client MUST validate the server's presented host key or
certificate.  This validation MAY be accomplished by certificate
path validation or by comparing the host key or certificate to a
previously trusted or "pinned" value.  If a certificate is
presented and it contains revocation-checking information, the
NETCONF/RESTCONF client SHOULD check the revocation status of the
certificate.  If it is determined that a certificate has been
revoked, the client MUST immediately close the connection.</p>
<p>C6  If certificate path validation is used, the NETCONF/RESTCONF
client MUST ensure that the presented certificate has a valid
chain of trust to a preconfigured issuer certificate, and that
the presented certificate encodes an "identifier" [RFC6125] that
the client was aware of before the connection attempt.  How
identifiers are encoded in certificates MAY be determined by a
policy associated with the certificate's issuer.  For instance, a
given issuer may be known to only sign IDevID certificates
[Std-802.1AR-2009] having a unique identifier (e.g., a serial
number) in the X.509 certificate's "CommonName" field.</p>
<p>C7  After the server's host key or certificate is validated, the SSH
or TLS protocol proceeds as normal to establish an SSH or TLS
connection.  When performing client authentication with the
NETCONF/RESTCONF server, the NETCONF/RESTCONF client MUST only
use credentials that it had previously associated for the
NETCONF/RESTCONF server's presented host key or server
certificate.</p>
<p>Watsen                       Standards Track                    [Page 6]

RFC 8071        NETCONF Call Home and RESTCONF Call Home   February 2017</p>
<p>C8  Once the SSH or TLS connection is established, the NETCONF/
RESTCONF client starts either the NETCONF client [RFC6241] or
RESTCONF client [RFC8040] protocol.  Assuming the use of the
IANA-assigned ports, the NETCONF client protocol is started when
the connection is accepted on either port 4334 or port 4335 and
the RESTCONF client protocol is started when the connection is
accepted on port 4336.</p>
<p>3.2.  Client Configuration Data Model</p>
<p>How a NETCONF or RESTCONF client is configured is outside the scope
of this document.  For instance, such a configuration might be used
to enable listening for call home connections, configuring trusted
certificate issuers, or configuring identifiers for expected
connections.  That said, YANG [RFC7950] data modules for configuring
NETCONF and RESTCONF clients, including call home, are provided in
[NETCONF-MODELS] and [RESTCONF-MODELS].</p>
<ol start="4">
<li>The NETCONF or RESTCONF Server</li>
</ol>
<p>The term "server" is defined in [RFC6241], Section 1.1.  In the
context of network management, the NETCONF/RESTCONF server might be a
network element or a device.</p>
<p>4.1.  Server Protocol Operation</p>
<p>S1  The NETCONF/RESTCONF server initiates a TCP connection request to
the NETCONF/RESTCONF client.  The source port may be per local
policy or randomly assigned by the operating system.  The server
MUST support connecting to one of the IANA-assigned ports defined
in Section 6, but MAY be configured to connect to a different
port.  Using the IANA-assigned ports, the server connects to port
4334 for NETCONF over SSH, port 4335 for NETCONF over TLS, and
port 4336 for RESTCONF over TLS.</p>
<p>S2  The TCP connection request is accepted and a TCP connection is
established.</p>
<p>S3  Using this TCP connection, the NETCONF/RESTCONF server starts
either the SSH server [RFC4253] or the TLS server [RFC5246]
protocol, depending on how it is configured.  For example,
assuming the use of the IANA-assigned ports, the SSH server
protocol is used after connecting to the remote port 4334 and the
TLS server protocol is used after connecting to either remote
port 4335 or remote port 4336.</p>
<p>Watsen                       Standards Track                    [Page 7]

RFC 8071        NETCONF Call Home and RESTCONF Call Home   February 2017</p>
<p>S4  As part of establishing the SSH or TLS connection, the NETCONF/
RESTCONF server will send its host key or certificate to the
client.  If a certificate is sent, the server MUST also send all
intermediate certificates leading up to a well-known and trusted
issuer.  How to send a list of certificates is defined for SSH in
[RFC6187], Section 2.1, and for TLS in [RFC5246], Section 7.4.2.</p>
<p>S5  Establishing an SSH or TLS session requires server authentication
of client credentials in all cases except with RESTCONF, where
some client authentication schemes occur after the secure
transport connection (TLS) has been established.  If transport-
level (SSH or TLS) client authentication is required, and the
client is unable to successfully authenticate itself to the
server in an amount of time defined by local policy, the server
MUST close the connection.</p>
<p>S6  Once the SSH or TLS connection is established, the NETCONF/
RESTCONF server starts either the NETCONF server [RFC6241] or
RESTCONF server [RFC8040] protocol, depending on how it is
configured.  Assuming the use of the IANA-assigned ports, the
NETCONF server protocol is used after connecting to remote port
4334 or remote port 4335, and the RESTCONF server protocol is
used after connecting to remote port 4336.</p>
<p>S7  If a persistent connection is desired, the NETCONF/RESTCONF
server, as the connection initiator, SHOULD actively test the
aliveness of the connection using a keep-alive mechanism.  For
TLS-based connections, the NETCONF/RESTCONF server SHOULD send
HeartbeatRequest messages, as defined by [RFC6520].  For SSH-
based connections, per Section 4 of [RFC4254], the server SHOULD
send an SSH_MSG_GLOBAL_REQUEST message with a purposely
nonexistent "request name" value (e.g., keepalive@ietf.org) and
the "want reply" value set to '1'.</p>
<p>4.2.  Server Configuration Data Model</p>
<p>How a NETCONF or RESTCONF server is configured is outside the scope
of this document.  This includes configuration that might be used to
specify hostnames, IP addresses, ports, algorithms, or other relevant
parameters.  That said, YANG [RFC7950] data modules for configuring
NETCONF and RESTCONF servers, including call home, are provided in
[NETCONF-MODELS] and [RESTCONF-MODELS].</p>
<p>Watsen                       Standards Track                    [Page 8]

RFC 8071        NETCONF Call Home and RESTCONF Call Home   February 2017</p>
<ol start="5">
<li>Security Considerations</li>
</ol>
<p>The security considerations described in [RFC6242] and [RFC7589], and
by extension [RFC4253], [RFC5246], and [RFC8040] apply here as well.</p>
<p>This RFC deviates from standard SSH and TLS usage by having the SSH/
TLS server initiate the underlying TCP connection.  This reversal is
incongruous with [RFC4253], which says "the client initiates the
connection" and also [RFC6125], which says "the client MUST construct
a list of acceptable reference identifiers, and MUST do so
independently of the identifiers presented by the service."</p>
<p>Risks associated with these variances are centered around server
authentication and the inability for clients to compare an
independently constructed reference identifier to one presented by
the server.  To mitigate against these risks, this RFC requires that
the NETCONF/RESTCONF client validate the server's SSH host key or
certificate, by certificate path validation to a preconfigured issuer
certificate, or by comparing the host key or certificate to a
previously trusted or "pinned" value.  Furthermore, when a
certificate is used, this RFC requires that the client be able to
match an identifier encoded in the presented certificate with an
identifier the client was preconfigured to expect (e.g., a serial
number).</p>
<p>For cases when the NETCONF/RESTCONF server presents an X.509
certificate, NETCONF/RESTCONF clients should ensure that the
preconfigured issuer certificate used for certificate path validation
is unique to the manufacturer of the server.  That is, the
certificate should not belong to a third-party certificate authority
that might issue certificates for more than one manufacturer.  This
is especially important when a client authentication mechanism
passing a shared secret (e.g., a password) to the server is used.
Not doing so could otherwise lead to a case where the client sends
the shared secret to another server that happens to have the same
identity (e.g., a serial number) as the server the client was
configured to expect.</p>
<p>Considerations not associated with server authentication follow next.</p>
<p>Internet-facing hosts running NETCONF Call Home or RESTCONF Call Home
will be fingerprinted via scanning tools such as "zmap" [zmap].  Both
SSH and TLS provide many ways in which a host can be fingerprinted.
SSH and TLS servers are fairly mature and able to withstand attacks,
but SSH and TLS clients may not be as robust.  Implementers and
deployments need to ensure that software update mechanisms are
provided so that vulnerabilities can be fixed in a timely fashion.</p>
<p>Watsen                       Standards Track                    [Page 9]

RFC 8071        NETCONF Call Home and RESTCONF Call Home   February 2017</p>
<p>An attacker could launch a denial-of-service (DoS) attack on the
NETCONF/RESTCONF client by having it perform computationally
expensive operations, before deducing that the attacker doesn't
possess a valid key.  For instance, in TLS 1.3 [TLS1.3], the
ClientHello message contains a Key Share value based on an expensive
asymmetric key operation.  Common precautions mitigating DoS attacks
are recommended, such as temporarily blacklisting the source address
after a set number of unsuccessful login attempts.</p>
<p>When using call home with the RESTCONF protocol, special care is
required when using some HTTP authentication schemes, especially the
Basic [RFC7617] and Digest [RFC7616] schemes, which convey a shared
secret (e.g., a password).  Implementers and deployments should be
sure to review the Security Considerations section in the RFC for any
HTTP client authentication scheme used.</p>
<ol start="6">
<li>IANA Considerations</li>
</ol>
<p>IANA has assigned three TCP port numbers in the "User Ports" range
with the service names "netconf-ch-ssh", "netconf-ch-tls", and
"restconf-ch-tls".  These ports will be the default ports for NETCONF
Call Home and RESTCONF Call Home protocols.  Below is the
registration template following the rules in [RFC6335].</p>
<p>Service Name:           netconf-ch-ssh
Port Number:            4334
Transport Protocol(s):  TCP
Description:            NETCONF Call Home (SSH)
Assignee:               IESG <a href="mailto:addons/iesg@ietf.org">iesg@ietf.org</a>
Contact:                IETF Chair <a href="mailto:addons/chair@ietf.org">chair@ietf.org</a>
Reference:              RFC 8071</p>
<p>Service Name:           netconf-ch-tls
Port Number:            4335
Transport Protocol(s):  TCP
Description:            NETCONF Call Home (TLS)
Assignee:               IESG <a href="mailto:addons/iesg@ietf.org">iesg@ietf.org</a>
Contact:                IETF Chair <a href="mailto:addons/chair@ietf.org">chair@ietf.org</a>
Reference:              RFC 8071</p>
<p>Service Name:           restconf-ch-tls
Port Number:            4336
Transport Protocol(s):  TCP
Description:            RESTCONF Call Home (TLS)
Assignee:               IESG <a href="mailto:addons/iesg@ietf.org">iesg@ietf.org</a>
Contact:                IETF Chair <a href="mailto:addons/chair@ietf.org">chair@ietf.org</a>
Reference:              RFC 8071</p>
<p>Watsen                       Standards Track                   [Page 10]

RFC 8071        NETCONF Call Home and RESTCONF Call Home   February 2017</p>
<ol start="7">
<li>References</li>
</ol>
<p>7.1.  Normative References</p>
<p>[RFC793]   Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<a href="http://www.rfc-editor.org/info/rfc793">http://www.rfc-editor.org/info/rfc793</a>.</p>
<p>[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>.</p>
<p>[RFC4251]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
January 2006, <a href="http://www.rfc-editor.org/info/rfc4251">http://www.rfc-editor.org/info/rfc4251</a>.</p>
<p>[RFC4252]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
January 2006, <a href="http://www.rfc-editor.org/info/rfc4252">http://www.rfc-editor.org/info/rfc4252</a>.</p>
<p>[RFC4253]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <a href="http://www.rfc-editor.org/info/rfc4253">http://www.rfc-editor.org/info/rfc4253</a>.</p>
<p>[RFC4254]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Connection Protocol", RFC 4254, DOI 10.17487/RFC4254,
January 2006, <a href="http://www.rfc-editor.org/info/rfc4254">http://www.rfc-editor.org/info/rfc4254</a>.</p>
<p>[RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<a href="http://www.rfc-editor.org/info/rfc5246">http://www.rfc-editor.org/info/rfc5246</a>.</p>
<p>[RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <a href="http://www.rfc-editor.org/info/rfc6125">http://www.rfc-editor.org/info/rfc6125</a>.</p>
<p>[RFC6187]  Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure
Shell Authentication", RFC 6187, DOI 10.17487/RFC6187,
March 2011, <a href="http://www.rfc-editor.org/info/rfc6187">http://www.rfc-editor.org/info/rfc6187</a>.</p>
<p>Watsen                       Standards Track                   [Page 11]

RFC 8071        NETCONF Call Home and RESTCONF Call Home   February 2017</p>
<p>[RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<a href="http://www.rfc-editor.org/info/rfc6241">http://www.rfc-editor.org/info/rfc6241</a>.</p>
<p>[RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<a href="http://www.rfc-editor.org/info/rfc6242">http://www.rfc-editor.org/info/rfc6242</a>.</p>
<p>[RFC6335]  Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011,
<a href="http://www.rfc-editor.org/info/rfc6335">http://www.rfc-editor.org/info/rfc6335</a>.</p>
<p>[RFC6520]  Seggelmann, R., Tuexen, M., and M. Williams, "Transport
Layer Security (TLS) and Datagram Transport Layer Security
(DTLS) Heartbeat Extension", RFC 6520,
DOI 10.17487/RFC6520, February 2012,
<a href="http://www.rfc-editor.org/info/rfc6520">http://www.rfc-editor.org/info/rfc6520</a>.</p>
<p>[RFC7589]  Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
NETCONF Protocol over Transport Layer Security (TLS) with
Mutual X.509 Authentication", RFC 7589,
DOI 10.17487/RFC7589, June 2015,
<a href="http://www.rfc-editor.org/info/rfc7589">http://www.rfc-editor.org/info/rfc7589</a>.</p>
<p>[RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<a href="http://www.rfc-editor.org/info/rfc8040">http://www.rfc-editor.org/info/rfc8040</a>.</p>
<p>7.2.  Informative References</p>
<p>[NETCONF-MODELS]
Watsen, K., Wu, G., and J. Schoenwaelder, "NETCONF Client
and Server Models", Work in Progress, draft-ietf-netconf-
netconf-client-server-01, November 2016.</p>
<p>[RESTCONF-MODELS]
Watsen, K. and J. Schoenwaelder, "RESTCONF Client and
Server Models", Work in Progress draft-ietf-netconf-
restconf-client-server-01, November 2016.</p>
<p>[RFC7616]  Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
Digest Access Authentication", RFC 7616,
DOI 10.17487/RFC7616, September 2015,
<a href="http://www.rfc-editor.org/info/rfc7616">http://www.rfc-editor.org/info/rfc7616</a>.</p>
<p>Watsen                       Standards Track                   [Page 12]

RFC 8071        NETCONF Call Home and RESTCONF Call Home   February 2017</p>
<p>[RFC7617]  Reschke, J., "The 'Basic' HTTP Authentication Scheme",
RFC 7617, DOI 10.17487/RFC7617, September 2015,
<a href="http://www.rfc-editor.org/info/rfc7617">http://www.rfc-editor.org/info/rfc7617</a>.</p>
<p>[RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<a href="http://www.rfc-editor.org/info/rfc7950">http://www.rfc-editor.org/info/rfc7950</a>.</p>
<p>[Std-802.1AR-2009]
IEEE, "IEEE Standard for Local and metropolitan area
networks - Secure Device Identity", IEEE Std 802.1AR-2009,
DOI 10.1109/IEEESTD.2009.5367679, December 2009,
&lt;http://standards.ieee.org/findstds/
standard/802.1AR-2009.html&gt;.</p>
<p>[TLS1.3]   Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", Work in Progress, draft-ietf-tls-tls13-18,
October 2016.</p>
<p>[zmap]     Durumeric, Z., Wustrow, E., and J. Halderman, "ZMap: Fast
Internet-Wide Scanning and its Security Applications",
22nd Usenix Security Symposium, August 2013,
<a href="https://zmap.io/paper.html">https://zmap.io/paper.html</a>.</p>
<p>Acknowledgements</p>
<p>The author would like to thank the following (ordered by last name)
for lively discussions on the mailing list and in the halls: Jari
Arkko, Andy Bierman, Martin Bjorklund, Ben Campbell, Spencer Dawkins,
Mehmet Ersue, Stephen Farrell, Wes Hardaker, Stephen Hanna, David
Harrington, Jeffrey Hutzelman, Simon Josefsson, Radek Krejci, Suresh
Krishnan, Barry Leiba, Alan Luchuk, Kathleen Moriarty, Mouse, Russ
Mundy, Tom Petch, Peter Saint-Andre, Joseph Salowey, Juergen
Schoenwaelder, Martin Stiemerling, Joe Touch, Hannes Tschofenig, Sean
Turner, and Bert Wijnen.</p>
<p>Author's Address</p>
<p>Kent Watsen
Juniper Networks</p>
<p>Email: kwatsen@juniper.net</p>
<p>Watsen                       Standards Track                   [Page 13]
</p>
<div style="break-before: page; page-break-before: always;"></div><p>Network Working Group                                       M. Wasserman
Request for Comments: 4742                                    ThingMagic
Category: Standards Track                                     T. Goddard
ICEsoft Technologies, Inc.
December 2006</p>
<pre><code>Using the NETCONF Configuration Protocol over Secure SHell (SSH)
</code></pre>
<p>Status of This Memo</p>
<p>This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements.  Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol.  Distribution of this memo is unlimited.</p>
<p>Copyright Notice</p>
<p>Copyright (C) The IETF Trust (2006).</p>
<p>Abstract</p>
<p>This document describes a method for invoking and running the Network
Configuration Protocol (NETCONF) within a Secure Shell (SSH) session
as an SSH subsystem.</p>
<p>Table of Contents</p>
<ol>
<li>Introduction ....................................................2</li>
<li>Requirements Terminology ........................................2</li>
<li>Starting NETCONF over SSH .......................................2
3.1. Capabilities Exchange ......................................3</li>
<li>Using NETCONF over SSH ..........................................5</li>
<li>Exiting the NETCONF Subsystem ...................................6</li>
<li>Security Considerations .........................................6</li>
<li>IANA Considerations .............................................7</li>
<li>Acknowledgements ................................................7</li>
<li>References ......................................................8
9.1. Normative References .......................................8
9.2. Informative References .....................................8</li>
</ol>
<p>Wasserman &amp; Goddard         Standards Track                     [Page 1]

RFC 4742                    NETCONF over SSH               December 2006</p>
<ol>
<li>Introduction</li>
</ol>
<p>The NETCONF protocol [RFC4721] is an XML-based protocol used to
manage the configuration of networking equipment.  NETCONF is defined
to be session-layer and transport independent, allowing mappings to
be defined for multiple session-layer or transport protocols.  This
document defines how NETCONF can be used within a Secure Shell (SSH)
session, using the SSH connection protocol [RFC4254] over the SSH
transport protocol [RFC4253].  This mapping will allow NETCONF to be
executed from a secure shell session by a user or application.</p>
<p>Throughout this document, the terms "client" and "server" are used to
refer to the two ends of the SSH transport connection.  The client
actively opens the SSH connection, and the server passively listens
for the incoming SSH connection.  The terms "manager" and "agent" are
used to refer to the two ends of the NETCONF protocol session.  The
manager issues NETCONF remote procedure call (RPC) commands, and the
agent replies to those commands.  When NETCONF is run over SSH using
the mapping defined in this document, the client is always the
manager, and the server is always the agent.</p>
<ol start="2">
<li>Requirements Terminology</li>
</ol>
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].</p>
<ol start="3">
<li>Starting NETCONF over SSH</li>
</ol>
<p>To run NETCONF over SSH, the client will first establish an SSH
transport connection using the SSH transport protocol, and the client
and server will exchange keys for message integrity and encryption.
The client will then invoke the "ssh-userauth" service to
authenticate the user, as described in the SSH authentication
protocol [RFC4252].  Once the user has been successfully
authenticated, the client will invoke the "ssh-connection" service,
also known as the SSH connection protocol.</p>
<p>After the ssh-connection service is established, the client will open
a channel of type "session", which will result in an SSH session.</p>
<p>Once the SSH session has been established, the user (or application)
will invoke NETCONF as an SSH subsystem called "netconf".  Subsystem
support is a feature of SSH version 2 (SSHv2) and is not included in
SSHv1.  Running NETCONF as an SSH subsystem avoids the need for the
script to recognize shell prompts or skip over extraneous
information, such as a system message that is sent at shell start-up.
However, even when a subsystem is used, some extraneous messages may</p>
<p>Wasserman &amp; Goddard         Standards Track                     [Page 2]

RFC 4742                    NETCONF over SSH               December 2006</p>
<p>be printed by the user's start-up scripts.  Implementations MUST skip
over these messages by searching for an 'xml' start directive, which
MUST be followed by a <hello> element in the 'NETCONF' namespace.</p>
<p>In order to allow NETCONF traffic to be easily identified and
filtered by firewalls and other network devices, NETCONF servers MUST
default to providing access to the "netconf" SSH subsystem only when
the SSH session is established using the IANA-assigned TCP port
&lt;830&gt;.  Servers SHOULD be configurable to allow access to the netconf
SSH subsystem over other ports.</p>
<p>A user (or application) could use the following command line to
invoke NETCONF as an SSH subsystem on the IANA-assigned port:</p>
<p>[user@client]$ ssh -s server.example.org -p &lt;830&gt; netconf</p>
<p>Note that the -s option causes the command ("netconf") to be invoked
as an SSH subsystem.</p>
<p>3.1.  Capabilities Exchange</p>
<p>The server MUST indicate its capabilities by sending an XML document
containing a <hello> element as soon as the NETCONF session is
established.  The user (or application) can parse this message to
determine which NETCONF capabilities are supported by the server.</p>
<p>The client must also send an XML document containing a <hello>
element to indicate the client's capabilities to the server.  The
document containing the <hello> element MUST be the first XML
document that the client sends after the NETCONF session is
established.</p>
<p>The following example shows a capability exchange.  Messages sent by
the client are marked with "C:", and messages sent by the server are
marked with "S:".</p>
<p>Wasserman &amp; Goddard         Standards Track                     [Page 3]

RFC 4742                    NETCONF over SSH               December 2006</p>
<p>S: <?xml version="1.0" encoding="UTF-8"?>
S: <hello>
S:   <capabilities>
S:     <capability>
S:       urn:ietf:params:xml:ns:netconf:base:1.0
S:     </capability>
S:     <capability>
S:       urn:ietf:params:ns:netconf:capability:startup:1.0
S:     </capability>
S:   </capabilities>
S:   <session-id>4<session-id>
S: </hello>
S: ]]&gt;]]&gt;</p>
<p>C: <?xml version="1.0" encoding="UTF-8"?>
C: <hello>
C:   <capabilities>
C:     <capability>
C:       urn:ietf:params:xml:ns:netconf:base:1.0
C:     </capability>
C:   </capabilities>
C: </hello>
C: ]]&gt;]]&gt;</p>
<p>Although the example shows the server sending a <hello> message
followed by the client's message, both sides will send the message as
soon as the NETCONF subsystem is initialized, perhaps simultaneously.</p>
<p>As the previous example illustrates, a special character sequence,
]]&gt;]]&gt;, MUST be sent by both the client and the server after each XML
document in the NETCONF exchange.  This character sequence cannot
legally appear in an XML document, so it can be unambiguously used to
identify the end of the current document, allowing resynchronization
of the NETCONF exchange in the event of an XML syntax or parsing
error.</p>
<p>Wasserman &amp; Goddard         Standards Track                     [Page 4]

RFC 4742                    NETCONF over SSH               December 2006</p>
<ol start="4">
<li>Using NETCONF over SSH</li>
</ol>
<p>A NETCONF over SSH session consists of the manager and agent
exchanging complete XML documents.  Once the session has been
established and capabilities have been exchanged, the manager will
send complete XML documents containing <rpc> elements to the server,
and the agent will respond with complete XML documents containing
<rpc-reply> elements.</p>
<p>To continue the example given above, an NETCONF over SSH session to
retrieve a set of configuration information might look like this:</p>
<p>C: <?xml version="1.0" encoding="UTF-8"?>
C: <rpc message-id="105"
   C: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
C:   <get-config>
C:     <source><running/></source>
C:     <config xmlns="http://example.com/schema/1.2/config">
C:      <users/>
C:     </config>
C:   </get-config>
C: </rpc>
C: ]]&gt;]]&gt;</p>
<p>S: <?xml version="1.0" encoding="UTF-8"?>
S: <rpc-reply message-id="105"
   S: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
S:   <config xmlns="http://example.com/schema/1.2/config">
S:     <users>
S:       <user><name>root</name><type>superuser</type></user>
S:       <user><name>fred</name><type>admin</type></user>
S:       <user><name>barney</name><type>admin</type></user>
S:     </users>
S:   </config>
S: </rpc-reply>
S: ]]&gt;]]&gt;</p>
<p>Wasserman &amp; Goddard         Standards Track                     [Page 5]

RFC 4742                    NETCONF over SSH               December 2006</p>
<ol start="5">
<li>Exiting the NETCONF Subsystem</li>
</ol>
<p>Exiting NETCONF is accomplished using the <close-session> operation.
An agent will process RPC messages from the manager in the order in
which they are received.  When the agent processes a <close-session>
command, the agent shall respond and close the SSH session channel.
The agent MUST NOT process any RPC commands received on the current
session after the <close-session> command.</p>
<p>To continue the example used in previous sections, an existing
NETCONF subsystem session could be closed as follows:</p>
<p>C: <?xml version="1.0" encoding="UTF-8"?>
C: <rpc message-id="106"
   C: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
C:   <close-session/>
C: </rpc>
C: ]]&gt;]]&gt;</p>
<p>S: <?xml version="1.0" encoding="UTF-8"?>
S: <rpc-reply id="106"
   S: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
S:   <ok/>
S: </rpc-reply>
S: ]]&gt;]]&gt;</p>
<ol start="6">
<li>Security Considerations</li>
</ol>
<p>NETCONF is used to access configuration and state information and to
modify configuration information, so the ability to access this
protocol should be limited to users and systems that are authorized
to view the agent's configuration and state or to modify the agent's
configuration.</p>
<p>The identity of the server MUST be verified and authenticated by the
client according to local policy before password-based authentication
data or any configuration or state data is sent to or received from
the server.  The identity of the client MUST also be verified and
authenticated by the server according to local policy to ensure that
the incoming client request is legitimate before any configuration or
state data is sent to or received from the client.  Neither side
should establish a NETCONF over SSH connection with an unknown,
unexpected, or incorrect identity on the opposite side.</p>
<p>Configuration or state data may include sensitive information, such
as usernames or security keys.  So, NETCONF should only be used over
communications channels that provide strong encryption for data</p>
<p>Wasserman &amp; Goddard         Standards Track                     [Page 6]

RFC 4742                    NETCONF over SSH               December 2006</p>
<p>privacy.  This document defines a NETCONF over SSH mapping that
provides for support of strong encryption and authentication.</p>
<p>This document requires that servers default to allowing access to the
"netconf" SSH subsystem only when using a specific TCP port assigned
by IANA for this purpose.  This will allow NETCONF over SSH traffic
to be easily identified and filtered by firewalls and other network
nodes.  However, it will also allow NETCONF over SSH traffic to be
more easily identified by attackers.</p>
<p>This document also recommends that servers be configurable to allow
access to the "netconf" SSH subsystem over other ports.  Use of that
configuration option without corresponding changes to firewall or
network device configuration may unintentionally result in the
ability for nodes outside the firewall or other administrative
boundary to gain access to "netconf" SSH subsystem.</p>
<ol start="7">
<li>IANA Considerations</li>
</ol>
<p>IANA assigned a TCP port number that is the default port for NETCONF
over SSH sessions as defined in this document.</p>
<p>IANA assigned port &lt;830&gt; for this purpose.</p>
<p>IANA is also requested to assign "netconf" as an SSH Service Name as
defined in [RFC4250], as follows:</p>
<pre><code>        Service Name                  Reference
        -------------                 ---------
        netconf                       RFC 4742
</code></pre>
<ol start="8">
<li>Acknowledgements</li>
</ol>
<p>This document was written using the xml2rfc tool described in RFC
2629 [RFC2629].</p>
<p>Extensive input was received from the other members of the NETCONF
design team, including: Andy Bierman, Weijing Chen, Rob Enns, Wes
Hardaker, David Harrington, Eliot Lear, Simon Leinen, Phil Shafer,
Juergen Schoenwaelder, and Steve Waldbusser.  The following people
have also reviewed this document and provided valuable input: Olafur
Gudmundsson, Sam Hartman, Scott Hollenbeck, Bill Sommerfeld, and Bert
Wijnen.</p>
<p>Wasserman &amp; Goddard         Standards Track                     [Page 7]

RFC 4742                    NETCONF over SSH               December 2006</p>
<ol start="9">
<li>References</li>
</ol>
<p>9.1.  Normative References</p>
<p>[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.</p>
<p>[RFC4250]  Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH)
Protocol Assigned Numbers", RFC 4250, January 2006.</p>
<p>[RFC4252]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, January 2006.</p>
<p>[RFC4253]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, January 2006.</p>
<p>[RFC4254]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Connection Protocol", RFC 4254, January 2006.</p>
<p>[RFC4721]  Enns, R., Ed., "NETCONF Configuration Protocol", RFC 4721,
December 2006.</p>
<p>9.2.  Informative References</p>
<p>[RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.</p>
<p>Wasserman &amp; Goddard         Standards Track                     [Page 8]

RFC 4742                    NETCONF over SSH               December 2006</p>
<p>Authors' Addresses</p>
<p>Margaret Wasserman
ThingMagic
One Broadway, 5th Floor
Cambridge, MA  02142
USA</p>
<p>Phone: +1 781 405-7464
EMail: margaret@thingmagic.com
URI:   http://www.thingmagic.com</p>
<p>Ted Goddard
ICEsoft Technologies, Inc.
Suite 300, 1717 10th St. NW
Calgary, AB  T2M 4S2
Canada</p>
<p>Phone: +1 403 663-3322
EMail: ted.goddard@icesoft.com
URI:   http://www.icesoft.com</p>
<p>Wasserman &amp; Goddard         Standards Track                     [Page 9]

RFC 4742                    NETCONF over SSH               December 2006</p>
<p>Full Copyright Statement</p>
<p>Copyright (C) The IETF Trust (2006).</p>
<p>This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.</p>
<p>This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.</p>
<p>Intellectual Property</p>
<p>The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights.  Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.</p>
<p>Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.</p>
<p>The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard.  Please address the information to the IETF at
ietf-ipr@ietf.org.</p>
<p>Acknowledgement</p>
<p>Funding for the RFC Editor function is currently provided by the
Internet Society.</p>
<p>Wasserman &amp; Goddard         Standards Track                    [Page 10]
</p>
<div style="break-before: page; page-break-before: always;"></div><p>Internet Engineering Task Force (IETF)                      M. Wasserman
Request for Comments: 6242                        Painless Security, LLC
Obsoletes: 4742                                                June 2011
Category: Standards Track
ISSN: 2070-1721</p>
<pre><code>       Using the NETCONF Protocol over Secure Shell (SSH)
</code></pre>
<p>Abstract</p>
<p>This document describes a method for invoking and running the Network
Configuration Protocol (NETCONF) within a Secure Shell (SSH) session
as an SSH subsystem.  This document obsoletes RFC 4742.</p>
<p>Status of This Memo</p>
<p>This is an Internet Standards Track document.</p>
<p>This document is a product of the Internet Engineering Task Force
(IETF).  It represents the consensus of the IETF community.  It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG).  Further information on
Internet Standards is available in Section 2 of RFC 5741.</p>
<p>Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6242.</p>
<p>Copyright Notice</p>
<p>Copyright (c) 2011 IETF Trust and the persons identified as the
document authors.  All rights reserved.</p>
<p>This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.  Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.</p>
<p>Wasserman                    Standards Track                    [Page 1]

RFC 6242                    NETCONF over SSH                   June 2011</p>
<p>Table of Contents</p>
<ol>
<li>
<p>Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2</p>
</li>
<li>
<p>Requirements Terminology . . . . . . . . . . . . . . . . . . .  2</p>
</li>
<li>
<p>Starting NETCONF over SSH  . . . . . . . . . . . . . . . . . .  2
3.1.  Capabilities Exchange  . . . . . . . . . . . . . . . . . .  3</p>
</li>
<li>
<p>Using NETCONF over SSH . . . . . . . . . . . . . . . . . . . .  4
4.1.  Framing Protocol . . . . . . . . . . . . . . . . . . . . .  5
4.2.  Chunked Framing Mechanism  . . . . . . . . . . . . . . . .  5
4.3.  End-of-Message Framing Mechanism . . . . . . . . . . . . .  7</p>
</li>
<li>
<p>Exiting the NETCONF Subsystem  . . . . . . . . . . . . . . . .  8</p>
</li>
<li>
<p>Security Considerations  . . . . . . . . . . . . . . . . . . .  8</p>
</li>
<li>
<p>IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9</p>
</li>
<li>
<p>Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10</p>
</li>
<li>
<p>References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A.  Changes from RFC 4742 . . . . . . . . . . . . . . . . 11</p>
</li>
<li>
<p>Introduction</p>
</li>
</ol>
<p>The NETCONF protocol [RFC6241] is an XML-based protocol used to
manage the configuration of networking equipment.  NETCONF is defined
to be session-layer and transport independent, allowing mappings to
be defined for multiple session-layer or transport protocols.  This
document defines how NETCONF can be used within a Secure Shell (SSH)
session, using the SSH connection protocol [RFC4254] over the SSH
transport protocol [RFC4253].  This mapping will allow NETCONF to be
executed from a secure shell session by a user or application.</p>
<p>Although this document gives specific examples of how NETCONF
messages are sent over an SSH connection, use of this transport is
not restricted to the messages shown in the examples below.  This
transport can be used for any NETCONF message.</p>
<ol start="2">
<li>Requirements Terminology</li>
</ol>
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].</p>
<ol start="3">
<li>Starting NETCONF over SSH</li>
</ol>
<p>To run NETCONF over SSH, the SSH client will first establish an SSH
transport connection using the SSH transport protocol, and the SSH
client and SSH server will exchange keys for message integrity and
encryption.  The SSH client will then invoke the "ssh-userauth"
service to authenticate the user, as described in the SSH</p>
<p>Wasserman                    Standards Track                    [Page 2]

RFC 6242                    NETCONF over SSH                   June 2011</p>
<p>authentication protocol [RFC4252].  Once the user has been
successfully authenticated, the SSH client will invoke the
"ssh-connection" service, also known as the SSH connection protocol.</p>
<p>The username provided by the SSH implementation will be made
available to the NETCONF message layer as the NETCONF username
without modification.  If the username does not comply to the NETCONF
requirements on usernames [RFC6241], i.e., the username is not
representable in XML, the SSH session MUST be dropped.  Any
transformations applied to the authenticated identity of the SSH
client made by the SSH server (e.g., via authentication services or
mappings to system accounts) are outside the scope of this document.</p>
<p>After the ssh-connection service is established, the SSH client will
open a channel of type "session", which will result in an SSH
session.</p>
<p>Once the SSH session has been established, the NETCONF client will
invoke NETCONF as an SSH subsystem called "netconf".  Subsystem
support is a feature of SSH version 2 (SSHv2) and is not included in
SSHv1.  Running NETCONF as an SSH subsystem avoids the need for the
script to recognize shell prompts or skip over extraneous
information, such as a system message that is sent at shell start-up.</p>
<p>In order to allow NETCONF traffic to be easily identified and
filtered by firewalls and other network devices, NETCONF servers MUST
default to providing access to the "netconf" SSH subsystem only when
the SSH session is established using the IANA-assigned TCP port 830.
Servers SHOULD be configurable to allow access to the netconf SSH
subsystem over other ports.</p>
<p>A user (or application) could use the following command line to
invoke NETCONF as an SSH subsystem on the IANA-assigned port:</p>
<p>[user@client]$ ssh -s server.example.org -p 830 netconf</p>
<p>Note that the -s option causes the command ("netconf") to be invoked
as an SSH subsystem.</p>
<p>3.1.  Capabilities Exchange</p>
<p>As specified in [RFC6241], the NETCONF server indicates its
capabilities by sending an XML document containing a <hello> element
as soon as the NETCONF session is established.  The NETCONF client
can parse this message to determine which NETCONF capabilities are
supported by the NETCONF server.</p>
<p>Wasserman                    Standards Track                    [Page 3]

RFC 6242                    NETCONF over SSH                   June 2011</p>
<p>As [RFC6241] states, the NETCONF client also sends an XML document
containing a <hello> element to indicate the NETCONF client's
capabilities to the NETCONF server.  The document containing the
<hello> element is the first XML document that the NETCONF client
sends after the NETCONF session is established.</p>
<p>The following example shows a capability exchange.  Data sent by the
NETCONF client are marked with "C:", and data sent by the NETCONF
server are marked with "S:".</p>
<p>S: <?xml version="1.0" encoding="UTF-8"?>
S: <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
S:   <capabilities>
S:     <capability>
S:       urn:ietf:params:netconf:base:1.1
S:     </capability>
S:     <capability>
S:       urn:ietf:params:ns:netconf:capability:startup:1.0
S:     </capability>
S:   </capabilities>
S:   <session-id>4</session-id>
S: </hello>
S: ]]&gt;]]&gt;</p>
<p>C: <?xml version="1.0" encoding="UTF-8"?>
C: <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
C:   <capabilities>
C:     <capability>
C:       urn:ietf:params:netconf:base:1.1
C:     </capability>
C:   </capabilities>
C: </hello>
C: ]]&gt;]]&gt;</p>
<p>Although the example shows the NETCONF server sending a <hello>
message followed by the NETCONF client's <hello> message, both sides
will send the message as soon as the NETCONF subsystem is
initialized, perhaps simultaneously.</p>
<ol start="4">
<li>Using NETCONF over SSH</li>
</ol>
<p>A NETCONF over SSH session consists of a NETCONF client and NETCONF
server exchanging complete XML documents.  Once the session has been
established and capabilities have been exchanged, the NETCONF client
will send complete XML documents containing <rpc> elements to the
server, and the NETCONF server will respond with complete XML
documents containing <rpc-reply> elements.</p>
<p>Wasserman                    Standards Track                    [Page 4]

RFC 6242                    NETCONF over SSH                   June 2011</p>
<p>4.1.  Framing Protocol</p>
<p>The previous version of this document defined the character sequence
"]]&gt;]]&gt;" as a message separator, under the assumption that it could
not be found in well-formed XML documents.  However, this assumption
is not correct.  It can legally appear in XML attributes, comments,
and processing instructions.  In order to solve this problem, and at
the same time be compatible with existing implementations, this
document defines the following framing protocol.</p>
<p>The <hello> message MUST be followed by the character sequence
]]&gt;]]&gt;.  Upon reception of the <hello> message, the receiving peer's
SSH Transport layer conceptually passes the <hello> message to the
Messages layer.  If the :base:1.1 capability is advertised by both
peers, the chunked framing mechanism (see Section 4.2) is used for
the remainder of the NETCONF session.  Otherwise, the old end-of-
message-based mechanism (see Section 4.3) is used.</p>
<p>4.2.  Chunked Framing Mechanism</p>
<p>This mechanism encodes all NETCONF messages with a chunked framing.
Specifically, the message follows the ABNF [RFC5234] rule Chunked-
Message:</p>
<pre><code>    Chunked-Message = 1*chunk
                      end-of-chunks

    chunk           = LF HASH chunk-size LF
                      chunk-data
    chunk-size      = 1*DIGIT1 0*DIGIT
    chunk-data      = 1*OCTET

    end-of-chunks   = LF HASH HASH LF

    DIGIT1          = %x31-39
    DIGIT           = %x30-39
    HASH            = %x23
    LF              = %x0A
    OCTET           = %x00-FF
</code></pre>
<p>The chunk-size field is a string of decimal digits indicating the
number of octets in chunk-data.  Leading zeros are prohibited, and
the maximum allowed chunk-size value is 4294967295.</p>
<p>Wasserman                    Standards Track                    [Page 5]

RFC 6242                    NETCONF over SSH                   June 2011</p>
<p>As an example, the message:</p>
<pre><code>   &lt;rpc message-id="102"
        xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
     &lt;close-session/&gt;
   &lt;/rpc&gt;
</code></pre>
<p>could be encoded as (using '\n' as a visible representation of the
LineFeed character):</p>
<p>C:  \n#4\n
C:  &lt;rpc
C:  \n#18\n
C:   message-id="102"\n
C:  \n#79\n
C:       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;\n
C:    <close-session/>\n
C:  </rpc>
C:  \n##\n</p>
<p>Conceptually, the SSH Transport layer encodes messages sent by the
Messages layer, and decodes messages received on the SSH channel
before passing them to the Messages layer.</p>
<p>The examples for the chunked framing mechanism show all LineFeeds,
even those that are not used as part of the framing mechanism.  Note
that the SSH transport does not interpret the XML content; thus, it
does not care about any optional XML-specific LineFeeds.</p>
<p>In the second and third chunks quoted above, each line is terminated
by a LineFeed.  For all the XML lines (except the last one), this
example treats the LineFeed as part of the chunk-data and so
contributing to the chunk-size.</p>
<p>Note that there is no LineFeed character after the <rpc> end tag in
this message.  The LineFeed required by the start of the end-of-
chunks block immediately follows the last '&gt;' character in the
message.</p>
<p>If the chunk-size and the chunk-size value respectively are invalid
or if an error occurs during the decoding process, the peer MUST
terminate the NETCONF session by closing the corresponding SSH
channel.  Implementations MUST ensure they are not vulnerable for a
buffer overrun.</p>
<p>Wasserman                    Standards Track                    [Page 6]

RFC 6242                    NETCONF over SSH                   June 2011</p>
<p>4.3.  End-of-Message Framing Mechanism</p>
<p>This mechanism exists for backwards compatibility with
implementations of previous versions of this document.  It is only
used when the remote peer does not advertise a base protocol version
supporting chunked encoding, i.e., a NETCONF implementation only
supporting :base:1.0.</p>
<p>When this mechanism is used, the special character sequence ]]&gt;]]&gt;,
MUST be sent by both the NETCONF client and the NETCONF server after
each message (XML document) in the NETCONF exchange.  Conceptually,
the SSH Transport layer passes any data found in between the ]]&gt;]]&gt;
characters to the Messages layer.</p>
<p>A NETCONF over SSH session, using the backwards-compatible end-of-
message framing to retrieve a set of configuration information, might
look like this:</p>
<p>C: <?xml version="1.0" encoding="UTF-8"?>
C: <rpc message-id="105"
   C: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
C:   <get-config>
C:     <source><running/></source>
C:     <config xmlns="http://example.com/schema/1.2/config">
C:      <users/>
C:     </config>
C:   </get-config>
C: </rpc>
C: ]]&gt;]]&gt;</p>
<p>S: <?xml version="1.0" encoding="UTF-8"?>
S: <rpc-reply message-id="105"
   S: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
S:   <config xmlns="http://example.com/schema/1.2/config">
S:     <users>
S:       <user><name>root</name><type>superuser</type></user>
S:       <user><name>fred</name><type>admin</type></user>
S:       <user><name>barney</name><type>admin</type></user>
S:     </users>
S:   </config>
S: </rpc-reply>
S: ]]&gt;]]&gt;</p>
<p>Wasserman                    Standards Track                    [Page 7]

RFC 6242                    NETCONF over SSH                   June 2011</p>
<ol start="5">
<li>Exiting the NETCONF Subsystem</li>
</ol>
<p>Exiting NETCONF is accomplished using the <close-session> operation.
A NETCONF server will process NETCONF messages from the NETCONF
client in the order in which they are received.  When the NETCONF
server processes a <close-session> operation, the NETCONF server
SHALL respond and close the SSH session channel.  The NETCONF server
MUST NOT process any NETCONF messages received after the
<close-session> operation.</p>
<p>To continue the example used in Section 4.2, an existing NETCONF
subsystem session could be closed as follows:</p>
<p>C: \n#140\n
C: <?xml version="1.0" encoding="UTF-8"?>\n
C: &lt;rpc message-id="106"\n
C:      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;\n
C:   <close-session/>\n
C: </rpc>
C: \n##\n</p>
<p>S: \n#139\n
S: <?xml version="1.0" encoding="UTF-8"?>\n
S: &lt;rpc-reply id="106"\n
S:            xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;\n
S:   <ok/>\n
S: </rpc-reply>
S: \n##\n</p>
<ol start="6">
<li>Security Considerations</li>
</ol>
<p>NETCONF is used to access configuration and state information and to
modify configuration information, so the ability to access this
protocol should be limited to users and systems that are authorized
to view the NETCONF server's configuration and state or to modify the
NETCONF server's configuration.</p>
<p>The identity of the SSH server MUST be verified and authenticated by
the SSH client according to local policy before password-based
authentication data or any configuration or state data is sent to or
received from the SSH server.  The identity of the SSH client MUST
also be verified and authenticated by the SSH server according to
local policy to ensure that the incoming SSH client request is
legitimate before any configuration or state data is sent to or
received from the SSH client.  Neither side should establish a
NETCONF over SSH connection with an unknown, unexpected, or incorrect
identity on the opposite side.</p>
<p>Wasserman                    Standards Track                    [Page 8]

RFC 6242                    NETCONF over SSH                   June 2011</p>
<p>Configuration or state data may include sensitive information, such
as usernames or security keys.  So, NETCONF requires communications
channels that provide strong encryption for data privacy.  This
document defines a NETCONF over SSH mapping that provides for support
of strong encryption and authentication.</p>
<p>This document requires that SSH servers default to allowing access to
the "netconf" SSH subsystem only when using a specific TCP port
assigned by IANA for this purpose.  This will allow NETCONF over SSH
traffic to be easily identified and filtered by firewalls and other
network nodes.  However, it will also allow NETCONF over SSH traffic
to be more easily identified by attackers.</p>
<p>This document also recommends that SSH servers be configurable to
allow access to the "netconf" SSH subsystem over other ports.  Use of
that configuration option without corresponding changes to firewall
or network device configuration may unintentionally result in the
ability for nodes outside of the firewall or other administrative
boundaries to gain access to the "netconf" SSH subsystem.</p>
<p>RFC 4742 assumes that the end-of-message (EOM) sequence, ]]&gt;]]&gt;,
cannot appear in any well-formed XML document, which turned out to be
mistaken.  The EOM sequence can cause operational problems and open
space for attacks if sent deliberately in RPC messages.  It is
however believed that the associated threat is not very high.  This
document still uses the EOM sequence for the initial <hello> message
to avoid incompatibility with existing implementations.  When both
peers implement base:1.1 capability, a proper framing protocol
(chunked framing mechanism; see Section 4.2) is used for the rest of
the NETCONF session, to avoid injection attacks.</p>
<ol start="7">
<li>IANA Considerations</li>
</ol>
<p>Based on the previous version of this document, RFC 4742, IANA
assigned the TCP port 830 as the default port for NETCONF over SSH
sessions.</p>
<p>IANA had also assigned "netconf" as an SSH Subsystem Name, as defined
in [RFC4250], as follows:</p>
<pre><code>          Subsystem Name                  Reference
          --------------                  ---------
          netconf                         RFC 4742
</code></pre>
<p>IANA updated these allocations to refer to this document.</p>
<p>Wasserman                    Standards Track                    [Page 9]

RFC 6242                    NETCONF over SSH                   June 2011</p>
<ol start="8">
<li>Acknowledgements</li>
</ol>
<p>Ted Goddard was a co-author on earlier versions of this document.</p>
<p>This document was written using the xml2rfc tool described in RFC
2629 [RFC2629].</p>
<p>Extensive input was received from the other members of the NETCONF
design team, including: Andy Bierman, Weijing Chen, Rob Enns, Wes
Hardaker, David Harrington, Eliot Lear, Simon Leinen, Phil Shafer,
Juergen Schoenwaelder, and Steve Waldbusser.  The following people
have also reviewed this document and provided valuable input: Olafur
Gudmundsson, Sam Hartman, Scott Hollenbeck, Bill Sommerfeld, Balazs
Lengyel, Bert Wijnen, Mehmet Ersue, Martin Bjorklund, Lada Lothka,
Kent Watsen, and Tom Petch.</p>
<ol start="9">
<li>References</li>
</ol>
<p>9.1.  Normative References</p>
<p>[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.</p>
<p>[RFC4250]  Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH)
Protocol Assigned Numbers", RFC 4250, January 2006.</p>
<p>[RFC4252]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, January 2006.</p>
<p>[RFC4253]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, January 2006.</p>
<p>[RFC4254]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Connection Protocol", RFC 4254, January 2006.</p>
<p>[RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.</p>
<p>[RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A.  Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, June 2011.</p>
<p>9.2.  Informative References</p>
<p>[RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.</p>
<p>Wasserman                    Standards Track                   [Page 10]

RFC 6242                    NETCONF over SSH                   June 2011</p>
<p>Appendix A.  Changes from RFC 4742</p>
<p>This section lists major changes between this document and RFC 4742.</p>
<p>o  Introduced the new chunked framing mechanism to solve known
security issues with the EOM framing.</p>
<p>o  Extended text in Security Considerations; added text on EOM
issues.</p>
<p>o  Added examples to show new chunked encoding properly; highlighted
the location of new lines.</p>
<p>o  Added text for NETCONF username handling following the
requirements on usernames in [RFC6241].</p>
<p>o  Changed use of the terms "client/server" and "manager/agent" to
"SSH client/server" and "NETCONF client/server".</p>
<p>o  Consistently used the term "operation", instead of "command" or
"message".</p>
<p>o  Integrated errata verified for RFC 4742 as of the date of
publication of this document.  See errata for RFC 4742 at
http://www.rfc-editor.org.</p>
<p>Author's Address</p>
<p>Margaret Wasserman
Painless Security, LLC
356 Abbott Street
North Andover, MA  01845
USA</p>
<p>Phone: +1 781 405-7464
EMail: mrw@painless-security.com
URI:   http://www.painless-security.com</p>
<p>Wasserman                    Standards Track                   [Page 11]
</p>
<div style="break-before: page; page-break-before: always;"></div><p>Network Working Group                                       R. Enns, Ed.
Request for Comments: 4741                              Juniper Networks
Category: Standards Track                                  December 2006</p>
<pre><code>                 NETCONF Configuration Protocol
</code></pre>
<p>Status of This Memo</p>
<p>This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements.  Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol.  Distribution of this memo is unlimited.</p>
<p>Copyright Notice</p>
<p>Copyright (C) The IETF Trust (2006).</p>
<p>Abstract</p>
<p>The Network Configuration Protocol (NETCONF) defined in this document
provides mechanisms to install, manipulate, and delete the
configuration of network devices.  It uses an Extensible Markup
Language (XML)-based data encoding for the configuration data as well
as the protocol messages.  The NETCONF protocol operations are
realized on top of a simple Remote Procedure Call (RPC) layer.</p>
<p>Enns                        Standards Track                     [Page 1]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>Table of Contents</p>
<ol>
<li>Introduction ....................................................5
1.1. Protocol Overview ..........................................6
1.2. Capabilities ...............................................7
1.3. Separation of Configuration and State Data .................7</li>
<li>Transport Protocol Requirements .................................8
2.1. Connection-Oriented Operation ..............................9
2.2. Authentication, Integrity, and Confidentiality .............9
2.3. Authentication .............................................9
2.4. Mandatory Transport Protocol ..............................10</li>
<li>XML Considerations .............................................10
3.1. Namespace .................................................10
3.2. No Document Type Declarations .............................10</li>
<li>RPC Model ......................................................10
4.1. <rpc> Element .............................................10
4.2. <rpc-reply> Element .......................................12
4.3. <rpc-error> Element .......................................12
4.4. <ok> Element ..............................................16
4.5. Pipelining ................................................16</li>
<li>Configuration Model ............................................16
5.1. Configuration Datastores ..................................16
5.2. Data Modeling .............................................17</li>
<li>Subtree Filtering ..............................................17
6.1. Overview ..................................................17
6.2. Subtree Filter Components .................................18
6.2.1. Namespace Selection ................................18
6.2.2. Attribute Match Expressions ........................19
6.2.3. Containment Nodes ..................................19
6.2.4. Selection Nodes ....................................20
6.2.5. Content Match Nodes ................................20
6.3. Subtree Filter Processing .................................22
6.4. Subtree Filtering Examples ................................22
6.4.1. No Filter ..........................................22
6.4.2. Empty Filter .......................................23
6.4.3. Select the Entire <users> Subtree ..................23
6.4.4. Select All <name> Elements within the
<users> Subtree ....................................25
6.4.5. One Specific <user> Entry ..........................26
6.4.6. Specific Elements from a Specific <user> Entry .....27
6.4.7. Multiple Subtrees ..................................28
6.4.8. Elements with Attribute Naming .....................29</li>
<li>Protocol Operations ............................................31
7.1. <get-config> ..............................................31
7.2. <edit-config> .............................................34
7.3. <copy-config> .............................................39
7.4. <delete-config> ...........................................41
7.5. <lock> ....................................................42</li>
</ol>
<p>Enns                        Standards Track                     [Page 2]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code>  7.6. &lt;unlock&gt; ..................................................44
  7.7. &lt;get&gt; .....................................................45
  7.8. &lt;close-session&gt; ...........................................47
  7.9. &lt;kill-session&gt; ............................................48
</code></pre>
<ol start="8">
<li>Capabilities ...................................................49
8.1. Capabilities Exchange .....................................49
8.2. Writable-Running Capability ...............................50
8.2.1. Description ........................................50
8.2.2. Dependencies .......................................50
8.2.3. Capability Identifier ..............................50
8.2.4. New Operations .....................................51
8.2.5. Modifications to Existing Operations ...............51
8.3. Candidate Configuration Capability ........................51
8.3.1. Description ........................................51
8.3.2. Dependencies .......................................52
8.3.3. Capability Identifier ..............................52
8.3.4. New Operations .....................................52
8.3.5. Modifications to Existing Operations ...............53
8.4. Confirmed Commit Capability ...............................55
8.4.1. Description ........................................55
8.4.2. Dependencies .......................................55
8.4.3. Capability Identifier ..............................56
8.4.4. New Operations .....................................56
8.4.5. Modifications to Existing Operations ...............56
8.5. Rollback on Error Capability ..............................57
8.5.1. Description ........................................57
8.5.2. Dependencies .......................................57
8.5.3. Capability Identifier ..............................57
8.5.4. New Operations .....................................57
8.5.5. Modifications to Existing Operations ...............57
8.6. Validate Capability .......................................58
8.6.1. Description ........................................58
8.6.2. Dependencies .......................................58
8.6.3. Capability Identifier ..............................58
8.6.4. New Operations .....................................58
8.7. Distinct Startup Capability ...............................60
8.7.1. Description ........................................60
8.7.2. Dependencies .......................................60
8.7.3. Capability Identifier ..............................60
8.7.4. New Operations .....................................60
8.7.5. Modifications to Existing Operations ...............60
8.8. URL Capability ............................................61
8.8.1. Description ........................................61
8.8.2. Dependencies .......................................61
8.8.3. Capability Identifier ..............................62
8.8.4. New Operations .....................................62
8.8.5. Modifications to Existing Operations ...............62</li>
</ol>
<p>Enns                        Standards Track                     [Page 3]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code>  8.9. XPath Capability ..........................................63
       8.9.1. Description ........................................63
       8.9.2. Dependencies .......................................63
       8.9.3. Capability Identifier ..............................63
       8.9.4. New Operations .....................................63
       8.9.5. Modifications to Existing Operations ...............63
</code></pre>
<ol start="9">
<li>Security Considerations ........................................64</li>
<li>IANA Considerations ...........................................66
10.1. NETCONF XML Namespace ....................................66
10.2. NETCONF XML Schema .......................................66
10.3. NETCONF Capability URNs ..................................66</li>
<li>Authors and Acknowledgements ..................................68</li>
<li>References ....................................................68
12.1. Normative References .....................................68
12.2. Informative References ...................................69
Appendix A. NETCONF Error List ....................................70
Appendix B. XML Schema for NETCONF RPC and Protocol Operations ....74
Appendix C. Capability Template ...................................86
C.1. capability-name (template) ................................86
C.1.1. Overview ...........................................86
C.1.2. Dependencies .......................................86
C.1.3. Capability Identifier ..............................86
C.1.4. New Operations .....................................86
C.1.5. Modifications to Existing Operations ...............86
C.1.6. Interactions with Other Capabilities ...............86
Appendix D.  Configuring Multiple Devices with NETCONF ............87
D.1. Operations on Individual Devices ..........................87
D.1.1. Acquiring the Configuration Lock ...................87
D.1.2. Loading the Update .................................88
D.1.3. Validating the Incoming Configuration ..............89
D.1.4. Checkpointing the Running Configuration ............89
D.1.5. Changing the Running Configuration .................90
D.1.6. Testing the New Configuration ......................91
D.1.7. Making the Change Permanent ........................91
D.1.8. Releasing the Configuration Lock ...................92
D.2. Operations on Multiple Devices ............................92
Appendix E. Deferred Features .....................................93</li>
</ol>
<p>Enns                        Standards Track                     [Page 4]

RFC 4741                    NETCONF Protocol               December 2006</p>
<ol>
<li>Introduction</li>
</ol>
<p>The NETCONF protocol defines a simple mechanism through which a
network device can be managed, configuration data information can be
retrieved, and new configuration data can be uploaded and
manipulated.  The protocol allows the device to expose a full, formal
application programming interface (API).  Applications can use this
straightforward API to send and receive full and partial
configuration data sets.</p>
<p>The NETCONF protocol uses a remote procedure call (RPC) paradigm.  A
client encodes an RPC in XML [1] and sends it to a server using a
secure, connection-oriented session.  The server responds with a
reply encoded in XML.  The contents of both the request and the
response are fully described in XML DTDs or XML schemas, or both,
allowing both parties to recognize the syntax constraints imposed on
the exchange.</p>
<p>A key aspect of NETCONF is that it allows the functionality of the
management protocol to closely mirror the native functionality of the
device.  This reduces implementation costs and allows timely access
to new features.  In addition, applications can access both the
syntactic and semantic content of the device's native user interface.</p>
<p>NETCONF allows a client to discover the set of protocol extensions
supported by a server.  These "capabilities" permit the client to
adjust its behavior to take advantage of the features exposed by the
device.  The capability definitions can be easily extended in a
noncentralized manner.  Standard and non-standard capabilities can be
defined with semantic and syntactic rigor.  Capabilities are
discussed in Section 8.</p>
<p>The NETCONF protocol is a building block in a system of automated
configuration.  XML is the lingua franca of interchange, providing a
flexible but fully specified encoding mechanism for hierarchical
content.  NETCONF can be used in concert with XML-based
transformation technologies, such as XSLT [8], to provide a system
for automated generation of full and partial configurations.  The
system can query one or more databases for data about networking
topologies, links, policies, customers, and services.  This data can
be transformed using one or more XSLT scripts from a task-oriented,
vendor-independent data schema into a form that is specific to the
vendor, product, operating system, and software release.  The
resulting data can be passed to the device using the NETCONF
protocol.</p>
<p>Enns                        Standards Track                     [Page 5]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3].</p>
<p>1.1.  Protocol Overview</p>
<p>NETCONF uses a simple RPC-based mechanism to facilitate communication
between a client and a server.  The client can be a script or
application typically running as part of a network manager.  The
server is typically a network device.  The terms "device" and
"server" are used interchangeably in this document, as are "client"
and "application".</p>
<p>A NETCONF session is the logical connection between a network
administrator or network configuration application and a network
device.  A device MUST support at least one NETCONF session and
SHOULD support multiple sessions.  Global configuration attributes
can be changed during any authorized session, and the effects are
visible in all sessions.  Session-specific attributes affect only the
session in which they are changed.</p>
<p>NETCONF can be conceptually partitioned into four layers:</p>
<pre><code>          Layer                      Example
     +-------------+      +-----------------------------+
 (4) |   Content   |      |     Configuration data      |
     +-------------+      +-----------------------------+
            |                           |
     +-------------+      +-----------------------------+
 (3) | Operations  |      | &lt;get-config&gt;, &lt;edit-config&gt; |
     +-------------+      +-----------------------------+
            |                           |
     +-------------+      +-----------------------------+
 (2) |     RPC     |      |    &lt;rpc&gt;, &lt;rpc-reply&gt;       |
     +-------------+      +-----------------------------+
            |                           |
     +-------------+      +-----------------------------+
 (1) |  Transport  |      |   BEEP, SSH, SSL, console   |
     |   Protocol  |      |                             |
     +-------------+      +-----------------------------+
</code></pre>
<ol>
<li>
<p>The transport protocol layer provides a communication path
between the client and server.  NETCONF can be layered over any
transport protocol that provides a set of basic requirements.
Section 2 discusses these requirements.</p>
</li>
<li>
<p>The RPC layer provides a simple, transport-independent framing
mechanism for encoding RPCs.  Section 4 documents this protocol.</p>
</li>
</ol>
<p>Enns                        Standards Track                     [Page 6]

RFC 4741                    NETCONF Protocol               December 2006</p>
<ol start="3">
<li>
<p>The operations layer defines a set of base operations invoked as
RPC methods with XML-encoded parameters.  Section 7 details the
list of base operations.</p>
</li>
<li>
<p>The content layer is outside the scope of this document.  Given
the current proprietary nature of the configuration data being
manipulated, the specification of this content depends on the
NETCONF implementation.  It is expected that a separate effort to
specify a standard data definition language and standard content
will be undertaken.</p>
</li>
</ol>
<p>1.2.  Capabilities</p>
<p>A NETCONF capability is a set of functionality that supplements the
base NETCONF specification.  The capability is identified by a
uniform resource identifier (URI).  These URIs should follow the
guidelines as described in Section 8.</p>
<p>Capabilities augment the base operations of the device, describing
both additional operations and the content allowed inside operations.
The client can discover the server's capabilities and use any
additional operations, parameters, and content defined by those
capabilities.</p>
<p>The capability definition may name one or more dependent
capabilities.  To support a capability, the server MUST support any
capabilities upon which it depends.</p>
<p>Section 8 defines the capabilities exchange that allows the client to
discover the server's capabilities.  Section 8 also lists the set of
capabilities defined in this document.</p>
<p>Additional capabilities can be defined at any time in external
documents, allowing the set of capabilities to expand over time.
Standards bodies may define standardized capabilities, and
implementations may define proprietary ones.  A capability URI MUST
sufficiently distinguish the naming authority to avoid naming
collisions.</p>
<p>1.3.  Separation of Configuration and State Data</p>
<p>The information that can be retrieved from a running system is
separated into two classes, configuration data and state data.
Configuration data is the set of writable data that is required to
transform a system from its initial default state into its current
state.  State data is the additional data on a system that is not</p>
<p>Enns                        Standards Track                     [Page 7]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>configuration data such as read-only status information and collected
statistics.  When a device is performing configuration operations, a
number of problems would arise if state data were included:</p>
<p>o  Comparisons of configuration data sets would be dominated by
irrelevant entries such as different statistics.</p>
<p>o  Incoming data could contain nonsensical requests, such as attempts
to write read-only data.</p>
<p>o  The data sets would be large.</p>
<p>o  Archived data could contain values for read-only data items,
complicating the processing required to restore archived data.</p>
<p>To account for these issues, the NETCONF protocol recognizes the
difference between configuration data and state data and provides
operations for each.  The <get-config> operation retrieves
configuration data only, while the <get> operation retrieves
configuration and state data.</p>
<p>Note that the NETCONF protocol is focused on the information required
to get the device into its desired running state.  The inclusion of
other important, persistent data is implementation specific.  For
example, user files and databases are not treated as configuration
data by the NETCONF protocol.</p>
<p>If a local database of user authentication data is stored on the
device, whether it is included in configuration data is an
implementation-dependent matter.</p>
<ol start="2">
<li>Transport Protocol Requirements</li>
</ol>
<p>NETCONF uses an RPC-based communication paradigm.  A client sends a
series of one or more RPC request operations, which cause the server
to respond with a corresponding series of RPC replies.</p>
<p>The NETCONF protocol can be layered on any transport protocol that
provides the required set of functionality.  It is not bound to any
particular transport protocol, but allows a mapping to define how it
can be implemented over any specific protocol.</p>
<p>The transport protocol MUST provide a mechanism to indicate the
session type (client or server) to the NETCONF protocol layer.</p>
<p>This section details the characteristics that NETCONF requires from
the underlying transport protocol.</p>
<p>Enns                        Standards Track                     [Page 8]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>2.1.  Connection-Oriented Operation</p>
<p>NETCONF is connection-oriented, requiring a persistent connection
between peers.  This connection must provide reliable, sequenced data
delivery.</p>
<p>NETCONF connections are long-lived, persisting between protocol
operations.  This allows the client to make changes to the state of
the connection that will persist for the lifetime of the connection.
For example, authentication information specified for a connection
remains in effect until the connection is closed.</p>
<p>In addition, resources requested from the server for a particular
connection MUST be automatically released when the connection closes,
making failure recovery simpler and more robust.  For example, when a
lock is acquired by a client, the lock persists until either it is
explicitly released or the server determines that the connection has
been terminated.  If a connection is terminated while the client
holds a lock, the server can perform any appropriate recovery.  The
lock operation is further discussed in Section 7.5.</p>
<p>2.2.  Authentication, Integrity, and Confidentiality</p>
<p>NETCONF connections must provide authentication, data integrity, and
confidentiality.  NETCONF depends on the transport protocol for this
capability.  A NETCONF peer assumes that appropriate levels of
security and confidentiality are provided independently of this
document.  For example, connections may be encrypted in TLS [9] or
SSH [10], depending on the underlying protocol.</p>
<p>2.3.  Authentication</p>
<p>NETCONF connections must be authenticated.  The transport protocol is
responsible for authentication.  The peer assumes that the
connection's authentication information has been validated by the
underlying protocol using sufficiently trustworthy mechanisms and
that the peer's identity has been sufficiently proven.</p>
<p>One goal of NETCONF is to provide a programmatic interface to the
device that closely follows the functionality of the device's native
interface.  Therefore, it is expected that the underlying protocol
uses existing authentication mechanisms defined by the device.  For
example, a device that supports RADIUS [11] should allow the use of
RADIUS to authenticate NETCONF sessions.</p>
<p>The authentication process should result in an identity whose
permissions are known to the device.  These permissions MUST be
enforced during the remainder of the NETCONF session.</p>
<p>Enns                        Standards Track                     [Page 9]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>2.4.  Mandatory Transport Protocol</p>
<p>A NETCONF implementation MUST support the SSH transport protocol
mapping [4].</p>
<ol start="3">
<li>XML Considerations</li>
</ol>
<p>XML serves as the encoding format for NETCONF, allowing complex
hierarchical data to be expressed in a text format that can be read,
saved, and manipulated with both traditional text tools and tools
specific to XML.</p>
<p>This section discusses a small number of XML-related considerations
pertaining to NETCONF.</p>
<p>3.1.  Namespace</p>
<p>All NETCONF protocol elements are defined in the following namespace:</p>
<pre><code>  urn:ietf:params:xml:ns:netconf:base:1.0
</code></pre>
<p>NETCONF capability names MUST be URIs [5].  NETCONF capabilities are
discussed in Section 8.</p>
<p>3.2.  No Document Type Declarations</p>
<p>Document type declarations MUST NOT appear in NETCONF content.</p>
<ol start="4">
<li>RPC Model</li>
</ol>
<p>The NETCONF protocol uses an RPC-based communication model.  NETCONF
peers use <rpc> and <rpc-reply> elements to provide transport
protocol-independent framing of NETCONF requests and responses.</p>
<p>4.1.  <rpc> Element</p>
<p>The <rpc> element is used to enclose a NETCONF request sent from the
client to the server.</p>
<p>The <rpc> element has a mandatory attribute "message-id", which is an
arbitrary string chosen by the sender of the RPC that will commonly
encode a monotonically increasing integer.  The receiver of the RPC
does not decode or interpret this string but simply saves it to be
used as a "message-id" attribute in any resulting <rpc-reply>
message.  For example:</p>
<p>Enns                        Standards Track                    [Page 10]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code>   &lt;rpc message-id="101"
        xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
     &lt;some-method&gt;
       &lt;!-- method parameters here... --&gt;
     &lt;/some-method&gt;
   &lt;/rpc&gt;
</code></pre>
<p>If additional attributes are present in an <rpc> element, a NETCONF
peer MUST return them unmodified in the <rpc-reply> element.</p>
<p>The name and parameters of an RPC are encoded as the contents of the
<rpc> element.  The name of the RPC is an element directly inside the
<rpc> element, and any parameters are encoded inside this element.</p>
<p>The following example invokes a method called <my-own-method>, which
has two parameters, <my-first-parameter>, with a value of "14", and
<another-parameter>, with a value of "fred":</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;my-own-method xmlns="http://example.net/me/my-own/1.0"&gt;
     &lt;my-first-parameter&gt;14&lt;/my-first-parameter&gt;
     &lt;another-parameter&gt;fred&lt;/another-parameter&gt;
   &lt;/my-own-method&gt;
 &lt;/rpc&gt;
</code></pre>
<p>The following example invokes a <rock-the-house> method with a
<zip-code> parameter of "27606-0100":</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;rock-the-house xmlns="http://example.net/rock/1.0"&gt;
     &lt;zip-code&gt;27606-0100&lt;/zip-code&gt;
   &lt;/rock-the-house&gt;
 &lt;/rpc&gt;
</code></pre>
<p>The following example invokes the NETCONF <get> method with no
parameters:</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;get/&gt;
 &lt;/rpc&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 11]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>4.2.  <rpc-reply> Element</p>
<p>The <rpc-reply> message is sent in response to an <rpc> operation.</p>
<p>The <rpc-reply> element has a mandatory attribute "message-id", which
is equal to the "message-id" attribute of the <rpc> for which this is
a response.</p>
<p>A NETCONF peer MUST also return any additional attributes included in
the <rpc> element unmodified in the <rpc-reply> element.</p>
<p>The response name and response data are encoded as the contents of
the <rpc-reply> element.  The name of the reply is an element
directly inside the <rpc-reply> element, and any data is encoded
inside this element.</p>
<p>For example:</p>
<p>The following <rpc> element invokes the NETCONF <get> method and
includes an additional attribute called "user-id".  Note that the
"user-id" attribute is not in the NETCONF namespace.  The returned
<rpc-reply> element returns the "user-id" attribute, as well as the
requested content.</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
      xmlns:ex="http://example.net/content/1.0"
      ex:user-id="fred"&gt;
   &lt;get/&gt;
 &lt;/rpc&gt;

 &lt;rpc-reply message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
      xmlns:ex="http://example.net/content/1.0"
      ex:user-id="fred"&gt;
   &lt;data&gt;
     &lt;!-- contents here... --&gt;
   &lt;/data&gt;
 &lt;/rpc-reply&gt;
</code></pre>
<p>4.3.  <rpc-error> Element</p>
<p>The <rpc-error> element is sent in <rpc-reply> messages if an error
occurs during the processing of an <rpc> request.</p>
<p>If a server encounters multiple errors during the processing of an
<rpc> request, the <rpc-reply> MAY contain multiple <rpc-error>
elements.  However, a server is not required to detect or report more</p>
<p>Enns                        Standards Track                    [Page 12]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>than one <rpc-error> element, if a request contains multiple errors.
A server is not required to check for particular error conditions in
a specific sequence.  A server MUST return an <rpc-error> element if
any error conditions occur during processing and SHOULD return an
<rpc-error> element if any warning conditions occur during
processing.</p>
<p>A server MUST NOT return application-level- or data-model-specific
error information in an <rpc-error> element for which the client does
not have sufficient access rights.</p>
<p>The <rpc-error> element includes the following information:</p>
<p>error-type: Defines the conceptual layer that the error occurred.
Enumeration.  One of:</p>
<pre><code>  *  transport

  *  rpc

  *  protocol

  *  application
</code></pre>
<p>error-tag: Contains a string identifying the error condition.  See
Appendix A for allowed values.</p>
<p>error-severity: Contains a string identifying the error severity, as
determined by the device.  One of:</p>
<pre><code>  *  error

  *  warning
</code></pre>
<p>error-app-tag: Contains a string identifying the data-model-specific
or implementation-specific error condition, if one exists.  This
element will not be present if no appropriate application error
tag can be associated with a particular error condition.</p>
<p>error-path: Contains the absolute XPath [2] expression identifying
the element path to the node that is associated with the error
being reported in a particular rpc-error element.  This element
will not be present if no appropriate payload element can be
associated with a particular error condition, or if the
'bad-element' QString returned in the 'error-info' container is
sufficient to identify the node associated with the error.  When</p>
<p>Enns                        Standards Track                    [Page 13]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code>  the XPath expression is interpreted, the set of namespace
  declarations are those in scope on the rpc-error element,
  including the default namespace.
</code></pre>
<p>error-message: Contains a string suitable for human display that
describes the error condition.  This element will not be present
if no appropriate message is provided for a particular error
condition.  This element SHOULD include an xml:lang attribute as
defined in [1] and discussed in [12].</p>
<p>error-info: Contains protocol- or data-model-specific error content.
This element will not be present if no such error content is
provided for a particular error condition.  The list in Appendix A
defines any mandatory error-info content for each error.  After
any protocol-mandated content, a data model definition may mandate
that certain application-layer error information be included in
the error-info container.  An implementation may include
additional elements to provide extended and/or implementation-
specific debugging information.</p>
<p>Appendix A enumerates the standard NETCONF errors.</p>
<p>Example:</p>
<pre><code>  An error is returned if an &lt;rpc&gt; element is received without a
  message-id attribute.  Note that only in this case is it
  acceptable for the NETCONF peer to omit the message-id attribute
  in the &lt;rpc-reply&gt; element.

 &lt;rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;get-config&gt;
     &lt;source&gt;
       &lt;running/&gt;
     &lt;/source&gt;
   &lt;/get-config&gt;
 &lt;/rpc&gt;

 &lt;rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;rpc-error&gt;
     &lt;error-type&gt;rpc&lt;/error-type&gt;
     &lt;error-tag&gt;missing-attribute&lt;/error-tag&gt;
     &lt;error-severity&gt;error&lt;/error-severity&gt;
     &lt;error-info&gt;
       &lt;bad-attribute&gt;message-id&lt;/bad-attribute&gt;
       &lt;bad-element&gt;rpc&lt;/bad-element&gt;
     &lt;/error-info&gt;
   &lt;/rpc-error&gt;
 &lt;/rpc-reply&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 14]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code>  The following &lt;rpc-reply&gt; illustrates the case of returning
  multiple &lt;rpc-error&gt; elements.

  Note that the data models used in the examples in this section use
  the &lt;name&gt; element to distinguish between multiple instances of
  the &lt;interface&gt; element.

 &lt;rpc-reply message-id="101"
   xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
   xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;rpc-error&gt;
     &lt;error-type&gt;application&lt;/error-type&gt;
     &lt;error-tag&gt;invalid-value&lt;/error-tag&gt;
     &lt;error-severity&gt;error&lt;/error-severity&gt;
     &lt;error-message xml:lang="en"&gt;
       MTU value 25000 is not within range 256..9192
     &lt;/error-message&gt;
     &lt;error-info&gt;
       &lt;top xmlns="http://example.com/schema/1.2/config"&gt;
         &lt;interface&gt;
           &lt;name&gt;Ethernet0/0&lt;/name&gt;
           &lt;mtu&gt;25000&lt;/mtu&gt;
         &lt;/interface&gt;
       &lt;/top&gt;
     &lt;/error-info&gt;
   &lt;/rpc-error&gt;
   &lt;rpc-error&gt;
     &lt;error-type&gt;application&lt;/error-type&gt;
     &lt;error-tag&gt;invalid-value&lt;/error-tag&gt;
     &lt;error-severity&gt;error&lt;/error-severity&gt;
     &lt;error-message xml:lang="en"&gt;
       Invalid IP address for interface Ethernet1/0
     &lt;/error-message&gt;
     &lt;error-info&gt;
       &lt;top xmlns="http://example.com/schema/1.2/config"&gt;
         &lt;interface xc:operation="replace"&gt;
           &lt;name&gt;Ethernet1/0&lt;/name&gt;
           &lt;address&gt;
             &lt;name&gt;1.4&lt;/name&gt;
             &lt;prefix-length&gt;24&lt;/prefix-length&gt;
           &lt;/address&gt;
         &lt;/interface&gt;
       &lt;/top&gt;
     &lt;/error-info&gt;
   &lt;/rpc-error&gt;
 &lt;/rpc-reply&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 15]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>4.4.  <ok> Element</p>
<p>The <ok> element is sent in <rpc-reply> messages if no errors or
warnings occurred during the processing of an <rpc> request.  For
example:</p>
<pre><code> &lt;rpc-reply message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;ok/&gt;
 &lt;/rpc-reply&gt;
</code></pre>
<p>4.5.  Pipelining</p>
<p>NETCONF <rpc> requests MUST be processed serially by the managed
device.  Additional <rpc> requests MAY be sent before previous ones
have been completed.  The managed device MUST send responses only in
the order the requests were received.</p>
<ol start="5">
<li>Configuration Model</li>
</ol>
<p>NETCONF provides an initial set of operations and a number of
capabilities that can be used to extend the base.  NETCONF peers
exchange device capabilities when the session is initiated as
described in Section 8.1.</p>
<p>5.1.  Configuration Datastores</p>
<p>NETCONF defines the existence of one or more configuration datastores
and allows configuration operations on them.  A configuration
datastore is defined as the complete set of configuration data that
is required to get a device from its initial default state into a
desired operational state.  The configuration datastore does not
include state data or executive commands.</p>
<p>Only the <running> configuration datastore is present in the base
model.  Additional configuration datastores may be defined by
capabilities.  Such configuration datastores are available only on
devices that advertise the capabilities.</p>
<p>o  Running: The complete configuration currently active on the
network device.  Only one configuration datastore of this type
exists on the device, and it is always present.  NETCONF protocol
operations refer to this datastore using the <running> element.</p>
<p>The capabilities in Sections 8.3 and 8.7 define the <candidate> and
<startup> configuration datastores, respectively.</p>
<p>Enns                        Standards Track                    [Page 16]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>5.2.  Data Modeling</p>
<p>Data modeling and content issues are outside the scope of the NETCONF
protocol.  An assumption is made that the device's data model is
well-known to the application and that both parties are aware of
issues such as the layout, containment, keying, lookup, replacement,
and management of the data, as well as any other constraints imposed
by the data model.</p>
<p>NETCONF carries configuration data inside the <config> element that
is specific to device's data model.  The protocol treats the contents
of that element as opaque data.  The device uses capabilities to
announce the set of data models that the device implements.  The
capability definition details the operation and constraints imposed
by data model.</p>
<p>Devices and managers may support multiple data models, including both
standard and proprietary data models.</p>
<ol start="6">
<li>Subtree Filtering</li>
</ol>
<p>6.1.  Overview</p>
<p>XML subtree filtering is a mechanism that allows an application to
select particular XML subtrees to include in the <rpc-reply> for a
<get> or <get-config> operation.  A small set of filters for
inclusion, simple content exact-match, and selection is provided,
which allows some useful, but also very limited, selection
mechanisms.  The agent does not need to utilize any data-model-
specific semantics during processing, allowing for simple and
centralized implementation strategies.</p>
<p>Conceptually, a subtree filter is comprised of zero or more element
subtrees, which represent the filter selection criteria.  At each
containment level within a subtree, the set of sibling nodes is
logically processed by the server to determine if its subtree and
path of elements to the root are included in the filter output.</p>
<p>All elements present in a particular subtree within a filter must
match associated nodes present in the server's conceptual data model.
XML namespaces may be specified (via 'xmlns' declarations) within the
filter data model.  If they are, the declared namespace must first
exactly match a namespace supported by the server.  Note that prefix
values for qualified namespaces are not relevant when comparing
filter elements to elements in the underlying data model.  Only data
associated with a specified namespace will be included in the filter
output.</p>
<p>Enns                        Standards Track                    [Page 17]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>Each node specified in a subtree filter represents an inclusive
filter.  Only associated nodes in underlying data model(s) within the
specified configuration datastore on the server are selected by the
filter.  A node must exactly match the namespace and hierarchy of
elements given in the filter data, except that the filter absolute
path name is adjusted to start from the layer below <filter>.</p>
<p>Response messages contain only the subtrees selected by the filter.
Any selection criteria that were present in the request, within a
particular selected subtree, are also included in the response.  Note
that some elements expressed in the filter as leaf nodes will be
expanded (i.e., subtrees included) in the filter output.  Specific
data instances are not duplicated in the response in the event that
the request contains multiple filter subtree expressions that select
the same data.</p>
<p>6.2.  Subtree Filter Components</p>
<p>A subtree filter is comprised of XML elements and their XML
attributes.  There are five types of components that may be present
in a subtree filter:</p>
<p>o  Namespace Selection</p>
<p>o  Attribute Match Expressions</p>
<p>o  Containment Nodes</p>
<p>o  Selection Nodes</p>
<p>o  Content Match Nodes</p>
<p>6.2.1.  Namespace Selection</p>
<p>If namespaces are used, then the filter output will only include
elements from the specified namespace.  A namespace is considered to
match (for filter purposes) if the content of the 'xmlns' attributes
are the same in the filter and the underlying data model.  Note that
namespace selection cannot be used by itself.  At least one element
must be specified in the filter any elements to be included in the
filter output.</p>
<p>Example:</p>
<pre><code> &lt;filter type="subtree"&gt;
   &lt;top xmlns="http://example.com/schema/1.2/config"/&gt;
 &lt;/filter&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 18]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>In this example, the <top> element is a selection node, and only this
node and any child nodes (from the underlying data model) in the
'http://example.com/schema/1.2/config' namespace will be included in
the filter output.</p>
<p>6.2.2.  Attribute Match Expressions</p>
<p>An attribute that appears in a subtree filter is part of an
"attribute match expression".  Any number of (unqualified or
qualified) XML attributes may be present in any type of filter node.
In addition to the selection criteria normally applicable to that
node, the selected data must have matching values for every attribute
specified in the node.  If an element is not defined to include a
specified attribute, then it is not selected in the filter output.</p>
<p>Example:</p>
<pre><code> &lt;filter type="subtree"&gt;
   &lt;t:top xmlns:t="http://example.com/schema/1.2/config"&gt;
     &lt;t:interfaces&gt;
       &lt;t:interface t:ifName="eth0"/&gt;
     &lt;/t:interfaces&gt;
   &lt;/t:top&gt;
 &lt;/filter&gt;
</code></pre>
<p>In this example, the <top>, <interfaces>, and <interface> elements
are containment nodes, and 'ifName' is an attribute match expression.
Only 'interface' nodes in the 'http://example.com/schema/1.2/config'
namespace that have an 'ifName' attribute with the value 'eth0' and
occur within 'interfaces' nodes within 'top' nodes will be included
in the filter output.</p>
<p>6.2.3.  Containment Nodes</p>
<p>Nodes that contain child elements within a subtree filter are called
"containment nodes".  Each child element can be any type of node,
including another containment node.  For each containment node
specified in a subtree filter, all data model instances that exactly
match the specified namespaces, element hierarchy, and any attribute
match expressions are included in the filter output.</p>
<p>Example:</p>
<pre><code> &lt;filter type="subtree"&gt;
   &lt;top xmlns="http://example.com/schema/1.2/config"&gt;
     &lt;users/&gt;
   &lt;/top&gt;
 &lt;/filter&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 19]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>In this example, the <top> element is a containment node.</p>
<p>6.2.4.  Selection Nodes</p>
<p>An empty leaf node within a filter is called a "selection node", and
it represents an "explicit selection" filter on the underlying data
model.  Presence of any selection nodes within a set of sibling nodes
will cause the filter to select the specified subtree(s) and suppress
automatic selection of the entire set of sibling nodes in the
underlying data model.  For filtering purposes, an empty leaf node
can be declared either with an empty tag (e.g., <foo/>) or with
explicit start and end tags (e.g., <foo> </foo>).  Any whitespace
characters are ignored in this form.</p>
<p>Example:</p>
<pre><code> &lt;filter type="subtree"&gt;
   &lt;top xmlns="http://example.com/schema/1.2/config"&gt;
     &lt;users/&gt;
   &lt;/top&gt;
 &lt;/filter&gt;
</code></pre>
<p>In this example, the <top> element is a containment node, and the
<users> element is a selection node.  Only 'users' nodes in the
'http://example.com/schema/1.2/config' namespace that occur within a
'top' element that is the root of the configuration datastore will be
included in the filter output.</p>
<p>6.2.5.  Content Match Nodes</p>
<p>A leaf node that contains simple content is called a "content match
node".  It is used to select some or all of its sibling nodes for
filter output, and it represents an exact-match filter on the leaf
node element content.  The following constraints apply to content
match nodes:</p>
<p>o  A content match node must not contain nested elements (i.e., must
resolve to a simpleType in the XML Schema Definition (XSD)).</p>
<p>o  Multiple content match nodes (i.e., sibling nodes) are logically
combined in an "AND" expression.</p>
<p>o  Filtering of mixed content is not supported.</p>
<p>o  Filtering of list content is not supported.</p>
<p>o  Filtering of whitespace-only content is not supported.</p>
<p>Enns                        Standards Track                    [Page 20]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>o  A content match node must contain non-whitespace characters.  An
empty element (e.g., <foo></foo>) will be interpreted as a
selection node (e.g., <foo/>).</p>
<p>o  Leading and trailing whitespace characters are ignored, but any
whitespace characters within a block of text characters are not
ignored or modified.</p>
<p>If all specified sibling content match nodes in a subtree filter
expression are 'true', then the filter output nodes are selected in
the following manner:</p>
<p>o  Each content match node in the sibling set is included in the
filter output.</p>
<p>o  If any containment nodes are present in the sibling set, then they
are processed further and included if any nested filter criteria
are also met.</p>
<p>o  If any selection nodes are present in the sibling set, then all of
them are included in the filter output.</p>
<p>o  Otherwise (i.e., there are no selection or containment nodes in
the filter sibling set), all the nodes defined at this level in
the underlying data model (and their subtrees, if any) are
returned in the filter output.</p>
<p>If any of the sibling content match node tests are 'false', then no
further filter processing is performed on that sibling set, and none
of the sibling subtrees are selected by the filter, including the
content match node(s).</p>
<p>Example:</p>
<pre><code> &lt;filter type="subtree"&gt;
   &lt;top xmlns="http://example.com/schema/1.2/config"&gt;
     &lt;users&gt;
       &lt;user&gt;
         &lt;name&gt;fred&lt;/name&gt;
       &lt;/user&gt;
     &lt;/users&gt;
   &lt;/top&gt;
 &lt;/filter&gt;
</code></pre>
<p>In this example, the <users> and <user> nodes are both containment
nodes, and <name> is a content match node.  Since no sibling nodes of
<name> are specified (and therefore no containment or selection
nodes), all of the sibling nodes of <name> are returned in the filter</p>
<p>Enns                        Standards Track                    [Page 21]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>output.  Only 'user' nodes in the
'http://example.com/schema/1.2/config' namespace that match the
element hierarchy and for which the <name> element is equal to 'fred'
will be included in the filter output.</p>
<p>6.3.  Subtree Filter Processing</p>
<p>The filter output (the set of selected nodes) is initially empty.</p>
<p>Each subtree filter can contain one or more data model fragments,
which represent portions of the data model that should be selected
(with all child nodes) in the filter output.</p>
<p>Each subtree data fragment is compared by the server to the internal
data models supported by the server.  If the entire subtree data-
fragment filter (starting from the root to the innermost element
specified in the filter) exactly matches a corresponding portion of
the supported data model, then that node and all its children are
included in the result data.</p>
<p>The server processes all nodes with the same parent node (sibling
set) together, starting from the root to the leaf nodes.  The root
elements in the filter are considered in the same sibling set
(assuming they are in the same namespace), even though they do not
have a common parent.</p>
<p>For each sibling set, the server determines which nodes are included
(or potentially included) in the filter output, and which sibling
subtrees are excluded (pruned) from the filter output.  The server
first determines which types of nodes are present in the sibling set
and processes the nodes according to the rules for their type.  If
any nodes in the sibling set are selected, then the process is
recursively applied to the sibling sets of each selected node.  The
algorithm continues until all sibling sets in all subtrees specified
in the filter have been processed.</p>
<p>6.4.  Subtree Filtering Examples</p>
<p>6.4.1.  No Filter</p>
<p>Leaving out the filter on the get operation returns the entire data
model.</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;get/&gt;
 &lt;/rpc&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 22]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code> &lt;rpc-reply message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;data&gt;
     &lt;!-- ... entire set of data returned ... --&gt;
   &lt;/data&gt;
 &lt;/rpc-reply&gt;
</code></pre>
<p>6.4.2.  Empty Filter</p>
<p>An empty filter will select nothing because no content match or
selection nodes are present.  This is not an error.  The filter type
attribute used in these examples is discussed further in Section 7.1.</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;get&gt;
     &lt;filter type="subtree"&gt;
     &lt;/filter&gt;
   &lt;/get&gt;
 &lt;/rpc&gt;

 &lt;rpc-reply message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;data&gt;
   &lt;/data&gt;
 &lt;/rpc-reply&gt;
</code></pre>
<p>6.4.3.  Select the Entire <users> Subtree</p>
<p>The filter in this example contains one selection node (<users>), so
just that subtree is selected by the filter.  This example represents
the fully-populated <users> data model in most of the filter examples
that follow.  In a real data model, the <company-info> would not
likely be returned with the list of users for a particular host or
network.</p>
<p>NOTE: The filtering and configuration examples used in this document
appear in the namespace "http://example.com/schema/1.2/config".  The
root element of this namespace is <top>.  The <top> element and its
descendents represent an example configuration data model only.</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;get-config&gt;
     &lt;source&gt;
       &lt;running/&gt;
     &lt;/source&gt;
     &lt;filter type="subtree"&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 23]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code>       &lt;top xmlns="http://example.com/schema/1.2/config"&gt;
         &lt;users/&gt;
       &lt;/top&gt;
     &lt;/filter&gt;
   &lt;/get-config&gt;
 &lt;/rpc&gt;

 &lt;rpc-reply message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;data&gt;
     &lt;top xmlns="http://example.com/schema/1.2/config"&gt;
       &lt;users&gt;
         &lt;user&gt;
           &lt;name&gt;root&lt;/name&gt;
           &lt;type&gt;superuser&lt;/type&gt;
           &lt;full-name&gt;Charlie Root&lt;/full-name&gt;
           &lt;company-info&gt;
             &lt;dept&gt;1&lt;/dept&gt;
             &lt;id&gt;1&lt;/id&gt;
           &lt;/company-info&gt;
         &lt;/user&gt;
         &lt;user&gt;
           &lt;name&gt;fred&lt;/name&gt;
           &lt;type&gt;admin&lt;/type&gt;
           &lt;full-name&gt;Fred Flintstone&lt;/full-name&gt;
           &lt;company-info&gt;
             &lt;dept&gt;2&lt;/dept&gt;
             &lt;id&gt;2&lt;/id&gt;
           &lt;/company-info&gt;
         &lt;/user&gt;
         &lt;user&gt;
           &lt;name&gt;barney&lt;/name&gt;
           &lt;type&gt;admin&lt;/type&gt;
           &lt;full-name&gt;Barney Rubble&lt;/full-name&gt;
           &lt;company-info&gt;
             &lt;dept&gt;2&lt;/dept&gt;
             &lt;id&gt;3&lt;/id&gt;
           &lt;/company-info&gt;
         &lt;/user&gt;
       &lt;/users&gt;
     &lt;/top&gt;
   &lt;/data&gt;
 &lt;/rpc-reply&gt;
</code></pre>
<p>The following filter request would have produced the same result, but
only because the container <users> defines one child element
(<user>).</p>
<p>Enns                        Standards Track                    [Page 24]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;get-config&gt;
     &lt;source&gt;
       &lt;running/&gt;
     &lt;/source&gt;
     &lt;filter type="subtree"&gt;
       &lt;top xmlns="http://example.com/schema/1.2/config"&gt;
         &lt;users&gt;
           &lt;user/&gt;
         &lt;/users&gt;
       &lt;/top&gt;
     &lt;/filter&gt;
   &lt;/get-config&gt;
 &lt;/rpc&gt;
</code></pre>
<p>6.4.4.  Select All <name> Elements within the <users> Subtree</p>
<p>This filter contains two containment nodes (<users>, <user>) and one
selector node (<name>).  All instances of the <name> element in the
same sibling set are selected in the filter output.  The manager may
need to know that <name> is used as an instance identifier in this
particular data structure, but the server does not need to know that
meta-data in order to process the request.</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;get-config&gt;
     &lt;source&gt;
       &lt;running/&gt;
     &lt;/source&gt;
     &lt;filter type="subtree"&gt;
       &lt;top xmlns="http://example.com/schema/1.2/config"&gt;
         &lt;users&gt;
           &lt;user&gt;
             &lt;name/&gt;
           &lt;/user&gt;
         &lt;/users&gt;
       &lt;/top&gt;
     &lt;/filter&gt;
   &lt;/get-config&gt;
 &lt;/rpc&gt;

 &lt;rpc-reply message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;data&gt;
     &lt;top xmlns="http://example.com/schema/1.2/config"&gt;
       &lt;users&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 25]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code>         &lt;user&gt;
           &lt;name&gt;root&lt;/name&gt;
         &lt;/user&gt;
         &lt;user&gt;
           &lt;name&gt;fred&lt;/name&gt;
         &lt;/user&gt;
         &lt;user&gt;
           &lt;name&gt;barney&lt;/name&gt;
         &lt;/user&gt;
       &lt;/users&gt;
     &lt;/top&gt;
   &lt;/data&gt;
 &lt;/rpc-reply&gt;
</code></pre>
<p>6.4.5.  One Specific <user> Entry</p>
<p>This filter contains two containment nodes (<users>, <user>) and one
content match node (<name>).  All instances of the sibling set
containing <name> for which the value of <name> equals "fred" are
selected in the filter output.</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;get-config&gt;
     &lt;source&gt;
       &lt;running/&gt;
     &lt;/source&gt;
     &lt;filter type="subtree"&gt;
       &lt;top xmlns="http://example.com/schema/1.2/config"&gt;
         &lt;users&gt;
           &lt;user&gt;
             &lt;name&gt;fred&lt;/name&gt;
           &lt;/user&gt;
         &lt;/users&gt;
       &lt;/top&gt;
     &lt;/filter&gt;
   &lt;/get-config&gt;
 &lt;/rpc&gt;

 &lt;rpc-reply message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;data&gt;
     &lt;top xmlns="http://example.com/schema/1.2/config"&gt;
       &lt;users&gt;
         &lt;user&gt;
           &lt;name&gt;fred&lt;/name&gt;
           &lt;type&gt;admin&lt;/type&gt;
           &lt;full-name&gt;Fred Flintstone&lt;/full-name&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 26]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code>           &lt;company-info&gt;
             &lt;dept&gt;2&lt;/dept&gt;
             &lt;id&gt;2&lt;/id&gt;
           &lt;/company-info&gt;
         &lt;/user&gt;
       &lt;/users&gt;
     &lt;/top&gt;
   &lt;/data&gt;
 &lt;/rpc-reply&gt;
</code></pre>
<p>6.4.6.  Specific Elements from a Specific <user> Entry</p>
<p>This filter contains two containment nodes (<users>, <user>), one
content match node (<name>), and two selector nodes (<type>,
<full-name>).  All instances of the <type> and <full-name> elements
in the same sibling set containing <name> for which the value of
<name> equals "fred" are selected in the filter output.  The
<company-info> element is not included because the sibling set
contains selection nodes.</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;get-config&gt;
     &lt;source&gt;
       &lt;running/&gt;
     &lt;/source&gt;
     &lt;filter type="subtree"&gt;
       &lt;top xmlns="http://example.com/schema/1.2/config"&gt;
         &lt;users&gt;
           &lt;user&gt;
             &lt;name&gt;fred&lt;/name&gt;
             &lt;type/&gt;
             &lt;full-name/&gt;
           &lt;/user&gt;
         &lt;/users&gt;
       &lt;/top&gt;
     &lt;/filter&gt;
   &lt;/get-config&gt;
 &lt;/rpc&gt;

 &lt;rpc-reply message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;data&gt;
     &lt;top xmlns="http://example.com/schema/1.2/config"&gt;
       &lt;users&gt;
         &lt;user&gt;
           &lt;name&gt;fred&lt;/name&gt;
           &lt;type&gt;admin&lt;/type&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 27]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code>           &lt;full-name&gt;Fred Flintstone&lt;/full-name&gt;
         &lt;/user&gt;
       &lt;/users&gt;
     &lt;/top&gt;
   &lt;/data&gt;
 &lt;/rpc-reply&gt;
</code></pre>
<p>6.4.7.  Multiple Subtrees</p>
<p>This filter contains three subtrees (name=root, fred, barney).</p>
<p>The "root" subtree filter contains two containment nodes (<users>,
<user>), one content match node (<name>), and one selector node
(<company-info>).  The subtree selection criteria is met, and just
the company-info subtree for "root" is selected in the filter output.</p>
<p>The "fred" subtree filter contains three containment nodes (<users>,
<user>, <company-info>), one content match node (<name>), and one
selector node (<id>).  The subtree selection criteria is met, and
just the <id> element within the company-info subtree for "fred" is
selected in the filter output.</p>
<p>The "barney" subtree filter contains three containment nodes
(<users>, <user>, <company-info>), two content match nodes (<name>,
<type>), and one selector node (<dept>).  The subtree selection
criteria is not met because user "barney" is not a "superuser", and
the entire subtree for "barney" (including its parent <user> entry)
is excluded from the filter output.</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;get-config&gt;
     &lt;source&gt;
       &lt;running/&gt;
     &lt;/source&gt;
     &lt;filter type="subtree"&gt;
       &lt;top xmlns="http://example.com/schema/1.2/config"&gt;
         &lt;users&gt;
           &lt;user&gt;
             &lt;name&gt;root&lt;/name&gt;
             &lt;company-info/&gt;
           &lt;/user&gt;
           &lt;user&gt;
             &lt;name&gt;fred&lt;/name&gt;
             &lt;company-info&gt;
               &lt;id/&gt;
             &lt;/company-info&gt;
           &lt;/user&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 28]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code>           &lt;user&gt;
             &lt;name&gt;barney&lt;/name&gt;
             &lt;type&gt;superuser&lt;/type&gt;
             &lt;company-info&gt;
               &lt;dept/&gt;
             &lt;/company-info&gt;
           &lt;/user&gt;
         &lt;/users&gt;
       &lt;/top&gt;
     &lt;/filter&gt;
   &lt;/get-config&gt;
 &lt;/rpc&gt;

 &lt;rpc-reply message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;data&gt;
     &lt;top xmlns="http://example.com/schema/1.2/config"&gt;
       &lt;users&gt;
         &lt;user&gt;
           &lt;name&gt;root&lt;/name&gt;
           &lt;company-info&gt;
             &lt;dept&gt;1&lt;/dept&gt;
             &lt;id&gt;1&lt;/id&gt;
           &lt;/company-info&gt;
         &lt;/user&gt;
         &lt;user&gt;
           &lt;name&gt;fred&lt;/name&gt;
           &lt;company-info&gt;
             &lt;id&gt;2&lt;/id&gt;
           &lt;/company-info&gt;
         &lt;/user&gt;
       &lt;/users&gt;
     &lt;/top&gt;
   &lt;/data&gt;
 &lt;/rpc-reply&gt;
</code></pre>
<p>6.4.8.  Elements with Attribute Naming</p>
<p>In this example, the filter contains one containment node
(<interfaces>), one attribute match expression (ifName), and one
selector node (<interface>).  All instances of the <interface>
subtree that have an ifName attribute equal to "eth0" are selected in
the filter output.  The filter data elements and attributes must be
qualified because the ifName attribute will not be considered part of
the 'schema/1.2' namespace if it is unqualified.</p>
<p>Enns                        Standards Track                    [Page 29]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;get&gt;
     &lt;filter type="subtree"&gt;
       &lt;t:top xmlns:t="http://example.com/schema/1.2/stats"&gt;
         &lt;t:interfaces&gt;
           &lt;t:interface t:ifName="eth0"/&gt;
         &lt;/t:interfaces&gt;
       &lt;/t:top&gt;
     &lt;/filter&gt;
   &lt;/get&gt;
 &lt;/rpc&gt;

 &lt;rpc-reply message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;data&gt;
     &lt;t:top xmlns:t="http://example.com/schema/1.2/stats"&gt;
       &lt;t:interfaces&gt;
         &lt;t:interface t:ifName="eth0"&gt;
           &lt;t:ifInOctets&gt;45621&lt;/t:ifInOctets&gt;
           &lt;t:ifOutOctets&gt;774344&lt;/t:ifOutOctets&gt;
         &lt;/t:interface&gt;
       &lt;/t:interfaces&gt;
     &lt;/t:top&gt;
   &lt;/data&gt;
 &lt;/rpc-reply&gt;
</code></pre>
<p>If ifName were a child node instead of an attribute, then the
following request would produce similar results.</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;get&gt;
     &lt;filter type="subtree"&gt;
       &lt;top xmlns="http://example.com/schema/1.2/stats"&gt;
         &lt;interfaces&gt;
           &lt;interface&gt;
             &lt;ifName&gt;eth0&lt;/ifName&gt;
           &lt;/interface&gt;
         &lt;/interfaces&gt;
       &lt;/top&gt;
     &lt;/filter&gt;
   &lt;/get&gt;
 &lt;/rpc&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 30]

RFC 4741                    NETCONF Protocol               December 2006</p>
<ol start="7">
<li>Protocol Operations</li>
</ol>
<p>The NETCONF protocol provides a small set of low-level operations to
manage device configurations and retrieve device state information.
The base protocol provides operations to retrieve, configure, copy,
and delete configuration datastores.  Additional operations are
provided, based on the capabilities advertised by the device.</p>
<p>The base protocol includes the following protocol operations:</p>
<p>o  get</p>
<p>o  get-config</p>
<p>o  edit-config</p>
<p>o  copy-config</p>
<p>o  delete-config</p>
<p>o  lock</p>
<p>o  unlock</p>
<p>o  close-session</p>
<p>o  kill-session</p>
<p>A protocol operation may fail for various reasons, including
"operation not supported".  An initiator should not assume that any
operation will always succeed.  The return values in any RPC reply
should be checked for error responses.</p>
<p>The syntax and XML encoding of the protocol operations are formally
defined in the XML schema in Appendix B.  The following sections
describe the semantics of each protocol operation.</p>
<p>7.1.  <get-config></p>
<p>Description:</p>
<pre><code>  Retrieve all or part of a specified configuration.
</code></pre>
<p>Enns                        Standards Track                    [Page 31]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>Parameters:</p>
<pre><code>  source:

     Name of the configuration datastore being queried, such as
     &lt;running/&gt;.

  filter:

     The filter element identifies the portions of the device
     configuration to retrieve.  If this element is unspecified, the
     entire configuration is returned.

     The filter element may optionally contain a "type" attribute.
     This attribute indicates the type of filtering syntax used
     within the filter element.  The default filtering mechanism in
     NETCONF is referred to as subtree filtering and is described in
     Section 6.  The value "subtree" explicitly identifies this type
     of filtering.

     If the NETCONF peer supports the :xpath capability
     (Section 8.9), the value "xpath" may be used to indicate that
     the select attribute on the filter element contains an XPath
     expression.
</code></pre>
<p>Positive Response:</p>
<pre><code>  If the device can satisfy the request, the server sends an
  &lt;rpc-reply&gt; element containing a &lt;data&gt; element with the results
  of the query.
</code></pre>
<p>Negative Response:</p>
<pre><code>  An &lt;rpc-error&gt; element is included in the &lt;rpc-reply&gt; if the
  request cannot be completed for any reason.
</code></pre>
<p>Example: To retrieve the entire <users> subtree:</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;get-config&gt;
     &lt;source&gt;
       &lt;running/&gt;
     &lt;/source&gt;
     &lt;filter type="subtree"&gt;
       &lt;top xmlns="http://example.com/schema/1.2/config"&gt;
         &lt;users/&gt;
       &lt;/top&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 32]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code>     &lt;/filter&gt;
   &lt;/get-config&gt;
 &lt;/rpc&gt;

 &lt;rpc-reply message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;data&gt;
     &lt;top xmlns="http://example.com/schema/1.2/config"&gt;
       &lt;users&gt;
         &lt;user&gt;
           &lt;name&gt;root&lt;/name&gt;
           &lt;type&gt;superuser&lt;/type&gt;
           &lt;full-name&gt;Charlie Root&lt;/full-name&gt;
           &lt;company-info&gt;
             &lt;dept&gt;1&lt;/dept&gt;
             &lt;id&gt;1&lt;/id&gt;
           &lt;/company-info&gt;
         &lt;/user&gt;
         &lt;!-- additional &lt;user&gt; elements appear here... --&gt;
       &lt;/users&gt;
     &lt;/top&gt;
   &lt;/data&gt;
 &lt;/rpc-reply&gt;
</code></pre>
<p>If the configuration is available in multiple formats, such as XML
and text, an XML namespace can be used to specify which format is
desired.  In the following example, the client uses a specific
element (<config-text>) in a specific namespace to indicate to the
server the desire to receive the configuration in an alternative
format.  The server may support any number of distinct formats or
views into the configuration data, with the client using the <filter>
parameter to select between them.</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;get-config&gt;
     &lt;source&gt;
       &lt;running/&gt;
     &lt;/source&gt;
     &lt;filter type="subtree"&gt;
       &lt;!-- request a text version of the configuration --&gt;
       &lt;config-text xmlns="http://example.com/text/1.2/config"/&gt;
     &lt;/filter&gt;
   &lt;/get-config&gt;
 &lt;/rpc&gt;

 &lt;rpc-reply message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 33]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code>   &lt;data&gt;
     &lt;config-text xmlns="http://example.com/text/1.2/config"&gt;
       &lt;!-- configuration text... --&gt;
     &lt;/config-text&gt;
   &lt;/data&gt;
 &lt;/rpc-reply&gt;

  Section 6 contains additional examples of subtree filtering.
</code></pre>
<p>7.2.  <edit-config></p>
<p>Description:</p>
<pre><code>  The &lt;edit-config&gt; operation loads all or part of a specified
  configuration to the specified target configuration.  This
  operation allows the new configuration to be expressed in several
  ways, such as using a local file, a remote file, or inline.  If
  the target configuration does not exist, it will be created.  If a
  NETCONF peer supports the :url capability (Section 8.8), the &lt;url&gt;
  element can appear instead of the &lt;config&gt; parameter and should
  identify a local configuration file.

  The device analyzes the source and target configurations and
  performs the requested changes.  The target configuration is not
  necessarily replaced, as with the &lt;copy-config&gt; message.  Instead,
  the target configuration is changed in accordance with the
  source's data and requested operations.
</code></pre>
<p>Attributes:</p>
<pre><code>  operation:

     Elements in the &lt;config&gt; subtree may contain an "operation"
     attribute.  The attribute identifies the point in the
     configuration to perform the operation and MAY appear on
     multiple elements throughout the &lt;config&gt; subtree.

     If the operation attribute is not specified, the configuration
     is merged into the configuration datastore.

     The operation attribute has one of the following values:

     merge: The configuration data identified by the element
        containing this attribute is merged with the configuration
        at the corresponding level in the configuration datastore
        identified by the target parameter.  This is the default
        behavior.
</code></pre>
<p>Enns                        Standards Track                    [Page 34]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code>     replace: The configuration data identified by the element
        containing this attribute replaces any related configuration
        in the configuration datastore identified by the target
        parameter.  Unlike a &lt;copy-config&gt; operation, which replaces
        the entire target configuration, only the configuration
        actually present in the config parameter is affected.

     create: The configuration data identified by the element
        containing this attribute is added to the configuration if
        and only if the configuration data does not already exist on
        the device.  If the configuration data exists, an
        &lt;rpc-error&gt; element is returned with an &lt;error-tag&gt; value of
        data-exists.

     delete: The configuration data identified by the element
        containing this attribute is deleted in the configuration
        datastore identified by the target parameter.
</code></pre>
<p>Parameters:</p>
<pre><code>  target:

     Name of the configuration datastore being edited, such as
     &lt;running/&gt; or &lt;candidate/&gt;.

  default-operation:

     Selects the default operation (as described in the "operation"
     attribute) for this &lt;edit-config&gt; request.  The default value
     for the default-operation parameter is "merge".

     The default-operation parameter is optional, but if provided,
     it must have one of the following values:

     merge: The configuration data in the &lt;config&gt; parameter is
        merged with the configuration at the corresponding level in
        the target datastore.  This is the default behavior.

     replace: The configuration data in the &lt;config&gt; parameter
        completely replaces the configuration in the target
        datastore.  This is useful for loading previously saved
        configuration data.

     none: The target datastore is unaffected by the configuration
        in the &lt;config&gt; parameter, unless and until the incoming
        configuration data uses the "operation" attribute to request
        a different operation.  If the configuration in the &lt;config&gt;
        parameter contains data for which there is not a
</code></pre>
<p>Enns                        Standards Track                    [Page 35]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code>        corresponding level in the target datastore, an &lt;rpc-error&gt;
        is returned with an &lt;error-tag&gt; value of data-missing.
        Using "none" allows operations like "delete" to avoid
        unintentionally creating the parent hierarchy of the element
        to be deleted.

  test-option:

     The test-option element may be specified only if the device
     advertises the :validate capability (Section 8.6).

     The test-option element has one of the following values:

     test-then-set: Perform a validation test before attempting to
        set.  If validation errors occur, do not perform the
        &lt;edit-config&gt; operation.  This is the default test-option.

     set: Perform a set without a validation test first.

  error-option:

     The error-option element has one of the following values:

     stop-on-error: Abort the edit-config operation on first error.
        This is the default error-option.

     continue-on-error: Continue to process configuration data on
        error; error is recorded, and negative response is generated
        if any errors occur.

     rollback-on-error: If an error condition occurs such that an
        error severity &lt;rpc-error&gt; element is generated, the server
        will stop processing the edit-config operation and restore
        the specified configuration to its complete state at the
        start of this edit-config operation.  This option requires
        the server to support the :rollback-on-error capability
        described in Section 8.5.

  config:

     A hierarchy of configuration data as defined by one of the
     device's data models.  The contents MUST be placed in an
     appropriate namespace, to allow the device to detect the
     appropriate data model, and the contents MUST follow the
     constraints of that data model, as defined by its capability
     definition.  Capabilities are discussed in Section 8.
</code></pre>
<p>Enns                        Standards Track                    [Page 36]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>Positive Response:</p>
<pre><code>  If the device was able to satisfy the request, an &lt;rpc-reply&gt; is
  sent containing an &lt;ok&gt; element.
</code></pre>
<p>Negative Response:</p>
<pre><code>  An &lt;rpc-error&gt; response is sent if the request cannot be completed
  for any reason.
</code></pre>
<p>Example:</p>
<pre><code>  The &lt;edit-config&gt; examples in this section utilize a simple data
  model, in which multiple instances of the 'interface' element may
  be present, and an instance is distinguished by the 'name' element
  within each 'interface' element.

  Set the MTU to 1500 on an interface named "Ethernet0/0" in the
  running configuration:

 &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;edit-config&gt;
     &lt;target&gt;
       &lt;running/&gt;
     &lt;/target&gt;
     &lt;config&gt;
       &lt;top xmlns="http://example.com/schema/1.2/config"&gt;
         &lt;interface&gt;
           &lt;name&gt;Ethernet0/0&lt;/name&gt;
           &lt;mtu&gt;1500&lt;/mtu&gt;
         &lt;/interface&gt;
       &lt;/top&gt;
     &lt;/config&gt;
   &lt;/edit-config&gt;
 &lt;/rpc&gt;

 &lt;rpc-reply message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;ok/&gt;
 &lt;/rpc-reply&gt;

  Add an interface named "Ethernet0/0" to the running configuration,
  replacing any previous interface with that name:

 &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;edit-config&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 37]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code>     &lt;target&gt;
       &lt;running/&gt;
     &lt;/target&gt;
     &lt;config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
       &lt;top xmlns="http://example.com/schema/1.2/config"&gt;
         &lt;interface xc:operation="replace"&gt;
           &lt;name&gt;Ethernet0/0&lt;/name&gt;
           &lt;mtu&gt;1500&lt;/mtu&gt;
           &lt;address&gt;
             &lt;name&gt;192.0.2.4&lt;/name&gt;
             &lt;prefix-length&gt;24&lt;/prefix-length&gt;
           &lt;/address&gt;
         &lt;/interface&gt;
       &lt;/top&gt;
     &lt;/config&gt;
   &lt;/edit-config&gt;
 &lt;/rpc&gt;

 &lt;rpc-reply message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;ok/&gt;
 &lt;/rpc-reply&gt;

  Delete the configuration for an interface named "Ethernet0/0" from
  the running configuration:

 &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;edit-config&gt;
     &lt;target&gt;
       &lt;running/&gt;
     &lt;/target&gt;
     &lt;default-operation&gt;none&lt;/default-operation&gt;
     &lt;config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
       &lt;top xmlns="http://example.com/schema/1.2/config"&gt;
         &lt;interface xc:operation="delete"&gt;
           &lt;name&gt;Ethernet0/0&lt;/name&gt;
         &lt;/interface&gt;
       &lt;/top&gt;
     &lt;/config&gt;
   &lt;/edit-config&gt;
 &lt;/rpc&gt;

 &lt;rpc-reply message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;ok/&gt;
 &lt;/rpc-reply&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 38]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code>  Delete interface 192.0.2.4 from an OSPF area (other interfaces
  configured in the same area are unaffected):

 &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;edit-config&gt;
     &lt;target&gt;
       &lt;running/&gt;
     &lt;/target&gt;
     &lt;default-operation&gt;none&lt;/default-operation&gt;
     &lt;config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
       &lt;top xmlns="http://example.com/schema/1.2/config"&gt;
         &lt;protocols&gt;
           &lt;ospf&gt;
             &lt;area&gt;
               &lt;name&gt;0.0.0.0&lt;/name&gt;
               &lt;interfaces&gt;
                 &lt;interface xc:operation="delete"&gt;
                   &lt;name&gt;192.0.2.4&lt;/name&gt;
                 &lt;/interface&gt;
               &lt;/interfaces&gt;
             &lt;/area&gt;
           &lt;/ospf&gt;
         &lt;/protocols&gt;
       &lt;/top&gt;
     &lt;/config&gt;
   &lt;/edit-config&gt;
 &lt;/rpc&gt;

 &lt;rpc-reply message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;ok/&gt;
 &lt;/rpc-reply&gt;
</code></pre>
<p>7.3.  <copy-config></p>
<p>Description:</p>
<pre><code>  Create or replace an entire configuration datastore with the
  contents of another complete configuration datastore.  If the
  target datastore exists, it is overwritten.  Otherwise, a new one
  is created, if allowed.

  If a NETCONF peer supports the :url capability (Section 8.8), the
  &lt;url&gt; element can appear as the &lt;source&gt; or &lt;target&gt; parameter.

  Even if it advertises the :writable-running capability, a device
  may choose not to support the &lt;running/&gt; configuration datastore
</code></pre>
<p>Enns                        Standards Track                    [Page 39]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code>  as the &lt;target&gt; parameter of a &lt;copy-config&gt; operation.  A device
  may choose not to support remote-to-remote copy operations, where
  both the &lt;source&gt; and &lt;target&gt; parameters use the &lt;url&gt; element.

  If the source and target parameters identify the same URL or
  configuration datastore, an error MUST be returned with an error-
  tag containing invalid-value.
</code></pre>
<p>Parameters:</p>
<pre><code>  target:

     Name of the configuration datastore to use as the destination
     of the copy operation.

  source:

     Name of the configuration datastore to use as the source of the
     copy operation or the &lt;config&gt; element containing the
     configuration subtree to copy.
</code></pre>
<p>Positive Response:</p>
<pre><code>  If the device was able to satisfy the request, an &lt;rpc-reply&gt; is
  sent that includes an &lt;ok&gt; element.
</code></pre>
<p>Negative Response:</p>
<pre><code>  An &lt;rpc-error&gt; element is included within the &lt;rpc-reply&gt; if the
  request cannot be completed for any reason.
</code></pre>
<p>Example:</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;copy-config&gt;
     &lt;target&gt;
       &lt;running/&gt;
     &lt;/target&gt;
     &lt;source&gt;
       &lt;url&gt;https://user@example.com:passphrase/cfg/new.txt&lt;/url&gt;
     &lt;/source&gt;
   &lt;/copy-config&gt;
 &lt;/rpc&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 40]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code> &lt;rpc-reply message-id="101"
     xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;ok/&gt;
 &lt;/rpc-reply&gt;
</code></pre>
<p>7.4.  <delete-config></p>
<p>Description:</p>
<pre><code>  Delete a configuration datastore.  The &lt;running&gt; configuration
  datastore cannot be deleted.

  If a NETCONF peer supports the :url capability (Section 8.8), the
  &lt;url&gt; element can appear as the &lt;target&gt; parameter.
</code></pre>
<p>Parameters:</p>
<pre><code>  target:

     Name of the configuration datastore to delete.
</code></pre>
<p>Positive Response:</p>
<pre><code>  If the device was able to satisfy the request, an &lt;rpc-reply&gt; is
  sent that includes an &lt;ok&gt; element.
</code></pre>
<p>Negative Response:</p>
<pre><code>  An &lt;rpc-error&gt; element is included within the &lt;rpc-reply&gt; if the
  request cannot be completed for any reason.
</code></pre>
<p>Example:</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;delete-config&gt;
     &lt;target&gt;
       &lt;startup/&gt;
     &lt;/target&gt;
   &lt;/delete-config&gt;
 &lt;/rpc&gt;

  &lt;rpc-reply message-id="101"
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;ok/&gt;
 &lt;/rpc-reply&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 41]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>7.5.  <lock></p>
<p>Description:</p>
<pre><code>  The lock operation allows the client to lock the configuration
  system of a device.  Such locks are intended to be short-lived and
  allow a client to make a change without fear of interaction with
  other NETCONF clients, non-NETCONF clients (e.g., SNMP and command
  line interface (CLI) scripts), and human users.

  An attempt to lock the configuration MUST fail if an existing
  session or other entity holds a lock on any portion of the lock
  target.

  When the lock is acquired, the server MUST prevent any changes to
  the locked resource other than those requested by this session.
  SNMP and CLI requests to modify the resource MUST fail with an
  appropriate error.

  The duration of the lock is defined as beginning when the lock is
  acquired and lasting until either the lock is released or the
  NETCONF session closes.  The session closure may be explicitly
  performed by the client, or implicitly performed by the server
  based on criteria such as failure of the underlying transport, or
  simple inactivity timeout.  This criteria is dependent on the
  implementation and the underlying transport.

  The lock operation takes a mandatory parameter, target.  The
  target parameter names the configuration that will be locked.
  When a lock is active, using the &lt;edit-config&gt; operation on the
  locked configuration and using the locked configuration as a
  target of the &lt;copy-config&gt; operation will be disallowed by any
  other NETCONF session.  Additionally, the system will ensure that
  these locked configuration resources will not be modified by other
  non-NETCONF management operations such as SNMP and CLI.  The
  &lt;kill-session&gt; message (at the RPC layer) can be used to force the
  release of a lock owned by another NETCONF session.  It is beyond
  the scope of this document to define how to break locks held by
  other entities.

  A lock MUST not be granted if either of the following conditions
  is true:

  *  A lock is already held by any NETCONF session or another
     entity.
</code></pre>
<p>Enns                        Standards Track                    [Page 42]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code>  *  The target configuration is &lt;candidate&gt;, it has already been
     modified, and these changes have not been committed or rolled
     back.

  The server MUST respond with either an &lt;ok&gt; element or an
  &lt;rpc-error&gt;.

  A lock will be released by the system if the session holding the
  lock is terminated for any reason.
</code></pre>
<p>Parameters:</p>
<pre><code>  target:

     Name of the configuration datastore to lock.
</code></pre>
<p>Positive Response:</p>
<pre><code>  If the device was able to satisfy the request, an &lt;rpc-reply&gt; is
  sent that contains an &lt;ok&gt; element.
</code></pre>
<p>Negative Response:</p>
<pre><code>  An &lt;rpc-error&gt; element is included in the &lt;rpc-reply&gt; if the
  request cannot be completed for any reason.

  If the lock is already held, the &lt;error-tag&gt; element will be
  'lock-denied' and the &lt;error-info&gt; element will include the
  &lt;session-id&gt; of the lock owner.  If the lock is held by a non-
  NETCONF entity, a &lt;session-id&gt; of 0 (zero) is included.  Note that
  any other entity performing a lock on even a partial piece of a
  target will prevent a NETCONF lock (which is global) from being
  obtained on that target.
</code></pre>
<p>Example:</p>
<pre><code>  The following example shows a successful acquisition of a lock.

 &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;lock&gt;
     &lt;target&gt;
       &lt;running/&gt;
     &lt;/target&gt;
   &lt;/lock&gt;
 &lt;/rpc&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 43]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code> &lt;rpc-reply message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;ok/&gt; &lt;!-- lock succeeded --&gt;
 &lt;/rpc-reply&gt;
</code></pre>
<p>Example:</p>
<pre><code>  The following example shows a failed attempt to acquire a lock
  when the lock is already in use.


 &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;lock&gt;
     &lt;target&gt;
       &lt;running/&gt;
     &lt;/target&gt;
   &lt;/lock&gt;
 &lt;/rpc&gt;

 &lt;rpc-reply message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;rpc-error&gt; &lt;!-- lock failed --&gt;
     &lt;error-type&gt;protocol&lt;/error-type&gt;
     &lt;error-tag&gt;lock-denied&lt;/error-tag&gt;
     &lt;error-severity&gt;error&lt;/error-severity&gt;
     &lt;error-message&gt;
       Lock failed, lock is already held
     &lt;/error-message&gt;
     &lt;error-info&gt;
       &lt;session-id&gt;454&lt;/session-id&gt;
       &lt;!-- lock is held by NETCONF session 454 --&gt;
     &lt;/error-info&gt;
   &lt;/rpc-error&gt;
 &lt;/rpc-reply&gt;
</code></pre>
<p>7.6.  <unlock></p>
<p>Description:</p>
<pre><code>  The unlock operation is used to release a configuration lock,
  previously obtained with the &lt;lock&gt; operation.

  An unlock operation will not succeed if any of the following
  conditions are true:

  *  the specified lock is not currently active
</code></pre>
<p>Enns                        Standards Track                    [Page 44]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code>  *  the session issuing the &lt;unlock&gt; operation is not the same
     session that obtained the lock

  The server MUST respond with either an &lt;ok&gt; element or an
  &lt;rpc-error&gt;.
</code></pre>
<p>Parameters:</p>
<pre><code>  target:

     Name of the configuration datastore to unlock.

     A NETCONF client is not permitted to unlock a configuration
     datastore that it did not lock.
</code></pre>
<p>Positive Response:</p>
<pre><code>  If the device was able to satisfy the request, an &lt;rpc-reply&gt; is
  sent that contains an &lt;ok&gt; element.
</code></pre>
<p>Negative Response:</p>
<pre><code>  An &lt;rpc-error&gt; element is included in the &lt;rpc-reply&gt; if the
  request cannot be completed for any reason.
</code></pre>
<p>Example:</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;unlock&gt;
     &lt;target&gt;
      &lt;running/&gt;
     &lt;/target&gt;
   &lt;/unlock&gt;
 &lt;/rpc&gt;

 &lt;rpc-reply message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;ok/&gt;
 &lt;/rpc-reply&gt;
</code></pre>
<p>7.7.  <get></p>
<p>Description:</p>
<pre><code>  Retrieve running configuration and device state information.
</code></pre>
<p>Enns                        Standards Track                    [Page 45]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>Parameters:</p>
<pre><code>  filter:

     This parameter specifies the portion of the system
     configuration and state data to retrieve.  If this parameter is
     empty, all the device configuration and state information is
     returned.

     The filter element may optionally contain a 'type' attribute.
     This attribute indicates the type of filtering syntax used
     within the filter element.  The default filtering mechanism in
     NETCONF is referred to as subtree filtering and is described in
     Section 6.  The value 'subtree' explicitly identifies this type
     of filtering.

     If the NETCONF peer supports the :xpath capability
     (Section 8.9), the value "xpath" may be used to indicate that
     the select attribute of the filter element contains an XPath
     expression.
</code></pre>
<p>Positive Response:</p>
<pre><code>  If the device was able to satisfy the request, an &lt;rpc-reply&gt; is
  sent.  The &lt;data&gt; section contains the appropriate subset.
</code></pre>
<p>Negative Response:</p>
<pre><code>  An &lt;rpc-error&gt; element is included in the &lt;rpc-reply&gt; if the
  request cannot be completed for any reason.
</code></pre>
<p>Example:</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;get&gt;
     &lt;filter type="subtree"&gt;
       &lt;top xmlns="http://example.com/schema/1.2/stats"&gt;
         &lt;interfaces&gt;
           &lt;interface&gt;
             &lt;ifName&gt;eth0&lt;/ifName&gt;
           &lt;/interface&gt;
         &lt;/interfaces&gt;
       &lt;/top&gt;
     &lt;/filter&gt;
   &lt;/get&gt;
 &lt;/rpc&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 46]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code> &lt;rpc-reply message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;data&gt;
     &lt;top xmlns="http://example.com/schema/1.2/stats"&gt;
       &lt;interfaces&gt;
         &lt;interface&gt;
           &lt;ifName&gt;eth0&lt;/ifName&gt;
           &lt;ifInOctets&gt;45621&lt;/ifInOctets&gt;
           &lt;ifOutOctets&gt;774344&lt;/ifOutOctets&gt;
         &lt;/interface&gt;
       &lt;/interfaces&gt;
     &lt;/top&gt;
   &lt;/data&gt;
 &lt;/rpc-reply&gt;
</code></pre>
<p>7.8.  <close-session></p>
<p>Description:</p>
<pre><code>  Request graceful termination of a NETCONF session.

  When a NETCONF server receives a &lt;close-session&gt; request, it will
  gracefully close the session.  The server will release any locks
  and resources associated with the session and gracefully close any
  associated connections.  Any NETCONF requests received after a
  &lt;close-session&gt; request will be ignored.
</code></pre>
<p>Positive Response:</p>
<pre><code>  If the device was able to satisfy the request, an &lt;rpc-reply&gt; is
  sent that includes an &lt;ok&gt; element.
</code></pre>
<p>Negative Response:</p>
<pre><code>  An &lt;rpc-error&gt; element is included in the &lt;rpc-reply&gt; if the
  request cannot be completed for any reason.
</code></pre>
<p>Example:</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;close-session/&gt;
 &lt;/rpc&gt;

 &lt;rpc-reply message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;ok/&gt;
 &lt;/rpc-reply&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 47]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>7.9.  <kill-session></p>
<p>Description:</p>
<pre><code>  Force the termination of a NETCONF session.

  When a NETCONF entity receives a &lt;kill-session&gt; request for an
  open session, it will abort any operations currently in process,
  release any locks and resources associated with the session, and
  close any associated connections.

  If a NETCONF server receives a &lt;kill-session&gt; request while
  processing a confirmed commit (Section 8.4), it must restore the
  configuration to its state before the confirmed commit was issued.

  Otherwise, the &lt;kill-session&gt; operation does not roll back
  configuration or other device state modifications made by the
  entity holding the lock.
</code></pre>
<p>Parameters:</p>
<pre><code>  session-id:

     Session identifier of the NETCONF session to be terminated.  If
     this value is equal to the current session ID, an
     'invalid-value' error is returned.
</code></pre>
<p>Positive Response:</p>
<pre><code>  If the device was able to satisfy the request, an &lt;rpc-reply&gt; is
  sent that includes an &lt;ok&gt; element.
</code></pre>
<p>Negative Response:</p>
<pre><code>  An &lt;rpc-error&gt; element is included in the &lt;rpc-reply&gt; if the
  request cannot be completed for any reason.
</code></pre>
<p>Example:</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;kill-session&gt;
     &lt;session-id&gt;4&lt;/session-id&gt;
   &lt;/kill-session&gt;
 &lt;/rpc&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 48]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code> &lt;rpc-reply message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;ok/&gt;
 &lt;/rpc-reply&gt;
</code></pre>
<ol start="8">
<li>Capabilities</li>
</ol>
<p>This section defines a set of capabilities that a client or a server
MAY implement.  Each peer advertises its capabilities by sending them
during an initial capabilities exchange.  Each peer needs to
understand only those capabilities that it might use and MUST ignore
any capability received from the other peer that it does not require
or does not understand.</p>
<p>Additional capabilities can be defined using the template in
Appendix C.  Future capability definitions may be published as
standards by standards bodies or published as proprietary extensions.</p>
<p>A NETCONF capability is identified with a URI.  The base capabilities
are defined using URNs following the method described in RFC 3553
[6].  Capabilities defined in this document have the following
format:</p>
<pre><code>  urn:ietf:params:netconf:capability:{name}:1.0
</code></pre>
<p>where {name} is the name of the capability.  Capabilities are often
referenced in discussions and email using the shorthand :{name}.  For
example, the foo capability would have the formal name
"urn:ietf:params:netconf:capability:foo:1.0" and be called ":foo".
The shorthand form MUST NOT be used inside the protocol.</p>
<p>8.1.  Capabilities Exchange</p>
<p>Capabilities are advertised in messages sent by each peer during
session establishment.  When the NETCONF session is opened, each peer
(both client and server) MUST send a <hello> element containing a
list of that peer's capabilities.  Each peer MUST send at least the
base NETCONF capability, "urn:ietf:params:netconf:base:1.0".</p>
<p>A server sending the <hello> element MUST include a <session-id>
element containing the session ID for this NETCONF session.  A client
sending the <hello> element MUST NOT include a <session-id> element.</p>
<p>A server receiving a <session-id> element MUST NOT continue the
NETCONF session.  Similarly, a client that does not receive a
<session-id> element in the server's <hello> message MUST NOT
continue the NETCONF session.  In both cases, the underlying
transport should be closed.</p>
<p>Enns                        Standards Track                    [Page 49]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>In the following example, a server advertises the base NETCONF
capability, one NETCONF capability defined in the base NETCONF
document, and one implementation-specific capability.</p>
   <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <capabilities>
       <capability>
         urn:ietf:params:netconf:base:1.0
       </capability>
       <capability>
         urn:ietf:params:netconf:capability:startup:1.0
       </capability>
       <capability>
         http://example.net/router/2.3/myfeature
       </capability>
     </capabilities>
     <session-id>4</session-id>
   </hello>
<p>Each peer sends its <hello> element simultaneously as soon as the
connection is open.  A peer MUST NOT wait to receive the capability
set from the other side before sending its own set.</p>
<p>8.2.  Writable-Running Capability</p>
<p>8.2.1.  Description</p>
<p>The :writable-running capability indicates that the device supports
direct writes to the <running> configuration datastore.  In other
words, the device supports edit-config and copy-config operations
where the <running> configuration is the target.</p>
<p>8.2.2.  Dependencies</p>
<p>None.</p>
<p>8.2.3.  Capability Identifier</p>
<p>The :writable-running capability is identified by the following
capability string:</p>
<pre><code>  urn:ietf:params:netconf:capability:writable-running:1.0
</code></pre>
<p>Enns                        Standards Track                    [Page 50]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>8.2.4.  New Operations</p>
<p>None.</p>
<p>8.2.5.  Modifications to Existing Operations</p>
<p>8.2.5.1.  <edit-config></p>
<p>The :writable-running capability modifies the <edit-config> operation
to accept the <running> element as a <target>.</p>
<p>8.2.5.2.  <copy-config></p>
<p>The :writable-running capability modifies the <copy-config> operation
to accept the <running> element as a <target>.</p>
<p>8.3.  Candidate Configuration Capability</p>
<p>8.3.1.  Description</p>
<p>The candidate configuration capability, :candidate, indicates that
the device supports a candidate configuration datastore, which is
used to hold configuration data that can be manipulated without
impacting the device's current configuration.  The candidate
configuration is a full configuration data set that serves as a work
place for creating and manipulating configuration data.  Additions,
deletions, and changes may be made to this data to construct the
desired configuration data.  A <commit> operation may be performed at
any time that causes the device's running configuration to be set to
the value of the candidate configuration.</p>
<p>The <commit> operation effectively sets the running configuration to
the current contents of the candidate configuration.  While it could
be modeled as a simple copy, it is done as a distinct operation for a
number of reasons.  In keeping high-level concepts as first class
operations, we allow developers to see more clearly both what the
client is requesting and what the server must perform.  This keeps
the intentions more obvious, the special cases less complex, and the
interactions between operations more straightforward.  For example,
the :confirmed-commit capability (Section 8.4) would make no sense as
a "copy confirmed" operation.</p>
<p>The candidate configuration may be shared among multiple sessions.
Unless a client has specific information that the candidate
configuration is not shared, it must assume that other sessions may
be able to modify the candidate configuration at the same time.  It
is therefore prudent for a client to lock the candidate configuration
before modifying it.</p>
<p>Enns                        Standards Track                    [Page 51]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>The client can discard any uncommitted changes to the candidate
configuration by executing the <discard-changes> operation.  This
operation reverts the contents of the candidate configuration to the
contents of the running configuration.</p>
<p>8.3.2.  Dependencies</p>
<p>None.</p>
<p>8.3.3.  Capability Identifier</p>
<p>The :candidate capability is identified by the following capability
string:</p>
<pre><code>  urn:ietf:params:netconf:capability:candidate:1.0
</code></pre>
<p>8.3.4.  New Operations</p>
<p>8.3.4.1.  <commit></p>
<p>Description:</p>
<pre><code>     When a candidate configuration's content is complete, the
     configuration data can be committed, publishing the data set to
     the rest of the device and requesting the device to conform to
     the behavior described in the new configuration.

     To commit the candidate configuration as the device's new
     current configuration, use the &lt;commit&gt; operation.

     The &lt;commit&gt; operation instructs the device to implement the
     configuration data contained in the candidate configuration.
     If the device is unable to commit all of the changes in the
     candidate configuration datastore, then the running
     configuration MUST remain unchanged.  If the device does
     succeed in committing, the running configuration MUST be
     updated with the contents of the candidate configuration.

     If the system does not have the :candidate capability, the
     &lt;commit&gt; operation is not available.
</code></pre>
<p>Positive Response:</p>
<pre><code>     If the device was able to satisfy the request, an &lt;rpc-reply&gt;
     is sent that contains an &lt;ok&gt; element.
</code></pre>
<p>Enns                        Standards Track                    [Page 52]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>Negative Response:</p>
<pre><code>     An &lt;rpc-error&gt; element is included in the &lt;rpc-reply&gt; if the
     request cannot be completed for any reason.
</code></pre>
<p>Example:</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;commit/&gt;
 &lt;/rpc&gt;

 &lt;rpc-reply message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;ok/&gt;
 &lt;/rpc-reply&gt;
</code></pre>
<p>8.3.4.2.  <discard-changes></p>
<p>If the client decides that the candidate configuration should not be
committed, the <discard-changes> operation can be used to revert the
candidate configuration to the current running configuration.</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;discard-changes/&gt;
 &lt;/rpc&gt;
</code></pre>
<p>This operation discards any uncommitted changes by resetting the
candidate configuration with the content of the running
configuration.</p>
<p>8.3.5.  Modifications to Existing Operations</p>
<p>8.3.5.1.  <get-config>, <edit-config>, <copy-config>, and <validate></p>
<p>The candidate configuration can be used as a source or target of any
<get-config>, <edit-config>, <copy-config>, or <validate> operation
as a <source> or <target> parameter.  The <candidate> element is used
to indicate the candidate configuration:</p>
<p>Enns                        Standards Track                    [Page 53]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;get-config&gt; &lt;!-- any NETCONF operation --&gt;
     &lt;source&gt;
       &lt;candidate/&gt;
     &lt;/source&gt;
   &lt;/get-config&gt;
 &lt;/rpc&gt;
</code></pre>
<p>8.3.5.2.  <lock> and <unlock></p>
<p>The candidate configuration can be locked using the <lock> operation
with the <candidate> element as the <target> parameter:</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;lock&gt;
     &lt;target&gt;
       &lt;candidate/&gt;
     &lt;/target&gt;
   &lt;/lock&gt;
 &lt;/rpc&gt;
</code></pre>
<p>Similarly, the candidate configuration is unlocked using the
<candidate> element as the <target> parameter:</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;unlock&gt;
     &lt;target&gt;
       &lt;candidate/&gt;
     &lt;/target&gt;
   &lt;/unlock&gt;
 &lt;/rpc&gt;
</code></pre>
<p>When a client fails with outstanding changes to the candidate
configuration, recovery can be difficult.  To facilitate easy
recovery, any outstanding changes are discarded when the lock is
released, whether explicitly with the <unlock> operation or
implicitly from session failure.</p>
<p>Enns                        Standards Track                    [Page 54]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>8.4.  Confirmed Commit Capability</p>
<p>8.4.1.  Description</p>
<p>The :confirmed-commit capability indicates that the server will
support the <confirmed> and <confirm-timeout> parameters for the
<commit> protocol operation.  See Section 8.3 for further details on
the <commit> operation.</p>
<p>A confirmed commit operation MUST be reverted if a follow-up commit
(called the "confirming commit") is not issued within 600 seconds (10
minutes).  The timeout period can be adjusted with the
<confirm-timeout> element.  The confirming commit can itself include
a <confirmed> parameter.</p>
<p>If the session issuing the confirmed commit is terminated for any
reason before the confirm timeout expires, the server MUST restore
the configuration to its state before the confirmed commit was
issued.</p>
<p>If the device reboots for any reason before the confirm timeout
expires, the server MUST restore the configuration to its state
before the confirmed commit was issued.</p>
<p>If a confirming commit is not issued, the device will revert its
configuration to the state prior to the issuance of the confirmed
commit.  Note that any commit operation, including a commit which
introduces additional changes to the configuration, will serve as a
confirming commit.  Thus to cancel a confirmed commit and revert
changes without waiting for the confirm timeout to expire, the
manager can explicitly restore the configuration to its state before
the confirmed commit was issued.</p>
<p>For shared configurations, this feature can cause other configuration
changes (for example, via other NETCONF sessions) to be inadvertently
altered or removed, unless the configuration locking feature is used
(in other words, the lock is obtained before the edit-config
operation is started).  Therefore, it is strongly suggested that in
order to use this feature with shared configuration databases,
configuration locking should also be used.</p>
<p>8.4.2.  Dependencies</p>
<p>The :confirmed-commit capability is only relevant if the :candidate
capability is also supported.</p>
<p>Enns                        Standards Track                    [Page 55]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>8.4.3.  Capability Identifier</p>
<p>The :confirmed-commit capability is identified by the following
capability string:</p>
<pre><code>  urn:ietf:params:netconf:capability:confirmed-commit:1.0
</code></pre>
<p>8.4.4.  New Operations</p>
<p>None.</p>
<p>8.4.5.  Modifications to Existing Operations</p>
<p>8.4.5.1.  <commit></p>
<p>The :confirmed-commit capability allows 2 additional parameters to
the <commit> operation.</p>
<p>Parameters:</p>
<pre><code>  confirmed:

        Perform a confirmed commit operation.

  confirm-timeout:

        Timeout period for confirmed commit, in seconds.  If
        unspecified, the confirm timeout defaults to 600 seconds.
</code></pre>
<p>Example:</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;commit&gt;
     &lt;confirmed/&gt;
     &lt;confirm-timeout&gt;120&lt;/confirm-timeout&gt;
   &lt;/commit&gt;
 &lt;/rpc&gt;

 &lt;rpc-reply message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;ok/&gt;
 &lt;/rpc-reply&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 56]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>8.5.  Rollback on Error Capability</p>
<p>8.5.1.  Description</p>
<p>This capability indicates that the server will support the
'rollback-on-error' value in the <error-option> parameter to the
<edit-config> operation.</p>
<p>For shared configurations, this feature can cause other configuration
changes (for example, via other NETCONF sessions) to be inadvertently
altered or removed, unless the configuration locking feature is used
(in other words, the lock is obtained before the edit-config
operation is started).  Therefore, it is strongly suggested that in
order to use this feature with shared configuration databases,
configuration locking also be used.</p>
<p>8.5.2.  Dependencies</p>
<p>None</p>
<p>8.5.3.  Capability Identifier</p>
<p>The :rollback-on-error capability is identified by the following
capability string:</p>
<pre><code>  urn:ietf:params:netconf:capability:rollback-on-error:1.0
</code></pre>
<p>8.5.4.  New Operations</p>
<p>None.</p>
<p>8.5.5.  Modifications to Existing Operations</p>
<p>8.5.5.1.  <edit-config></p>
<p>The :rollback-on-error capability allows the 'rollback-on-error'
value to the <error-option> parameter on the <edit-config> operation.</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;edit-config&gt;
     &lt;target&gt;
       &lt;running/&gt;
     &lt;/target&gt;
     &lt;error-option&gt;rollback-on-error&lt;/error-option&gt;
     &lt;config&gt;
       &lt;top xmlns="http://example.com/schema/1.2/config"&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 57]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code>         &lt;interface&gt;
           &lt;name&gt;Ethernet0/0&lt;/name&gt;
           &lt;mtu&gt;100000&lt;/mtu&gt;
         &lt;/interface&gt;
       &lt;/top&gt;
     &lt;/config&gt;
   &lt;/edit-config&gt;
 &lt;/rpc&gt;

 &lt;rpc-reply message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;ok/&gt;
 &lt;/rpc-reply&gt;
</code></pre>
<p>8.6.  Validate Capability</p>
<p>8.6.1.  Description</p>
<p>Validation consists of checking a candidate configuration for
syntactical and semantic errors before applying the configuration to
the device.</p>
<p>If this capability is advertised, the device supports the <validate>
protocol operation and checks at least for syntax errors.  In
addition, this capability supports the test-option parameter to the
<edit-config> operation and, when it is provided, checks at least for
syntax errors.</p>
<p>8.6.2.  Dependencies</p>
<p>None.</p>
<p>8.6.3.  Capability Identifier</p>
<p>The :validate capability is identified by the following capability
string:</p>
<pre><code>  urn:ietf:params:netconf:capability:validate:1.0
</code></pre>
<p>8.6.4.  New Operations</p>
<p>8.6.4.1.  <validate></p>
<p>Description:</p>
<pre><code>     This protocol operation validates the contents of the specified
     configuration.
</code></pre>
<p>Enns                        Standards Track                    [Page 58]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>Parameters:</p>
<pre><code>  source:

        Name of the configuration datastore being validated, such as
        &lt;candidate&gt; or the &lt;config&gt; element containing the
        configuration subtree to validate.
</code></pre>
<p>Positive Response:</p>
<pre><code>     If the device was able to satisfy the request, an &lt;rpc-reply&gt;
     is sent that contains an &lt;ok&gt; element.
</code></pre>
<p>Negative Response:</p>
<pre><code>     An &lt;rpc-error&gt; element is included in the &lt;rpc-reply&gt; if the
     request cannot be completed for any reason.

     A validate operation can fail for any of the following reasons:

     +  Syntax errors

     +  Missing parameters

     +  References to undefined configuration data
</code></pre>
<p>Example:</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;validate&gt;
     &lt;source&gt;
       &lt;candidate/&gt;
     &lt;/source&gt;
   &lt;/validate&gt;
 &lt;/rpc&gt;

 &lt;rpc-reply message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;ok/&gt;
 &lt;/rpc-reply&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 59]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>8.7.  Distinct Startup Capability</p>
<p>8.7.1.  Description</p>
<p>The device supports separate running and startup configuration
datastores.  Operations that affect the running configuration will
not be automatically copied to the startup configuration.  An
explicit <copy-config> operation from the <running> to the <startup>
must be invoked to update the startup configuration to the current
contents of the running configuration.  NETCONF protocol operations
refer to the startup datastore using the <startup> element.</p>
<p>8.7.2.  Dependencies</p>
<p>None.</p>
<p>8.7.3.  Capability Identifier</p>
<p>The :startup capability is identified by the following capability
string:</p>
<pre><code>  urn:ietf:params:netconf:capability:startup:1.0
</code></pre>
<p>8.7.4.  New Operations</p>
<p>None.</p>
<p>8.7.5.  Modifications to Existing Operations</p>
<p>8.7.5.1.  General</p>
<p>The :startup capability adds the <startup/> configuration datastore
to arguments of several NETCONF operations.  The server MUST support
the following additional values:</p>
<p>Enns                        Standards Track                    [Page 60]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>+--------------------+--------------------------+-------------------+
| Operation          | Parameters               | Notes             |
+--------------------+--------------------------+-------------------+
| <get-config>       | <source>                 |                   |
|                    |                          |                   |
| <copy-config>      | <source> <target>        |                   |
|                    |                          |                   |
| <lock>             | <target>                 |                   |
|                    |                          |                   |
| <unlock>           | <target>                 |                   |
|                    |                          |                   |
| <validate>         | <source>                 | If :validate is   |
|                    |                          | advertised        |
+--------------------+--------------------------+-------------------+</p>
<p>To save the startup configuration, use the copy-config operation to
copy the <running> configuration datastore to the <startup>
configuration datastore.</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;copy-config&gt;
     &lt;source&gt;
       &lt;running/&gt;
     &lt;/source&gt;
     &lt;target&gt;
       &lt;startup/&gt;
     &lt;/target&gt;
   &lt;/copy-config&gt;
 &lt;/rpc&gt;
</code></pre>
<p>8.8.  URL Capability</p>
<p>8.8.1.  Description</p>
<p>The NETCONF peer has the ability to accept the <url> element in
<source> and <target> parameters.  The capability is further
identified by URL arguments indicating the URL schemes supported.</p>
<p>8.8.2.  Dependencies</p>
<p>None.</p>
<p>Enns                        Standards Track                    [Page 61]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>8.8.3.  Capability Identifier</p>
<p>The :url capability is identified by the following capability string:</p>
<p>urn:ietf:params:netconf:capability:url:1.0?scheme={name,...}</p>
<p>The :url capability URI MUST contain a "scheme" argument assigned a
comma-separated list of scheme names indicating which schemes the
NETCONF peer supports.  For example:</p>
<pre><code>  urn:ietf:params:netconf:capability:url:1.0?scheme=http,ftp,file
</code></pre>
<p>8.8.4.  New Operations</p>
<p>None.</p>
<p>8.8.5.  Modifications to Existing Operations</p>
<p>8.8.5.1.  <edit-config></p>
<p>The :url capability modifies the <edit-config> operation to accept
the <url> element as an alternative to the <config> parameter.  If
the <url> element is specified, then it should identify a local
configuration file.</p>
<p>8.8.5.2.  <copy-config></p>
<p>The :url capability modifies the <copy-config> operation to accept
the <url> element as the value of the <source> and the <target>
parameters.</p>
<p>8.8.5.3.  <delete-config></p>
<p>The :url capability modifies the <delete-config> operation to accept
the <url> element as the value of the <target> parameters.  If this
parameter contains a URL, then it should identify a local
configuration file.</p>
<p>8.8.5.4.  <validate></p>
<p>The :url capability modifies the <validate> operation to accept the
<url> element as the value of the <source> parameter.</p>
<p>Enns                        Standards Track                    [Page 62]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>8.9.  XPath Capability</p>
<p>8.9.1.  Description</p>
<p>The XPath capability indicates that the NETCONF peer supports the use
of XPath expressions in the <filter> element.  XPath is described in
[2].</p>
<p>The XPath expression must return a node-set.</p>
<p>The XPath expression is evaluated in a context where the context node
is the root node, and the set of namespace declarations are those in
scope on the filter element, including the default namespace.</p>
<p>8.9.2.  Dependencies</p>
<p>None.</p>
<p>8.9.3.  Capability Identifier</p>
<p>The :xpath capability is identified by the following capability
string:</p>
<pre><code>  urn:ietf:params:netconf:capability:xpath:1.0
</code></pre>
<p>8.9.4.  New Operations</p>
<p>None.</p>
<p>8.9.5.  Modifications to Existing Operations</p>
<p>8.9.5.1.  <get-config> and <get></p>
<p>The :xpath capability modifies the <get> and <get-config> operations
to accept the value "xpath" in the type attribute of the filter
element.  When the type attribute is set to "xpath", a select
attribute MUST be present on the filter element.  The select
attribute will be treated as an XPath expression and used to filter
the returned data.  The filter element itself MUST be empty in this
case.</p>
<p>For example:</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;get-config&gt;
     &lt;source&gt;
       &lt;running/&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 63]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code>     &lt;/source&gt;
     &lt;!-- get the user named fred --&gt;
     &lt;filter type="xpath" select="top/users/user[name='fred']"/&gt;
    &lt;/get-config&gt;
 &lt;/rpc&gt;
</code></pre>
<ol start="9">
<li>Security Considerations</li>
</ol>
<p>This document does not specify an authorization scheme, as such a
scheme should be tied to a meta-data model or a data model.
Implementors SHOULD provide a comprehensive authorization scheme with
NETCONF.</p>
<p>Authorization of individual users via the NETCONF server may or may
not map 1:1 to other interfaces.  First, the data models may be
incompatible.  Second, it may be desirable to authorize based on
mechanisms available in the transport protocol layer (TELNET, SSH,
etc).</p>
<p>In addition, operations on configurations may have unintended
consequences if those operations are also not guarded by the global
lock on the files or objects being operated upon.  For instance, a
partially complete access list could be committed from a candidate
configuration unbeknownst to the owner of the lock of the candidate
configuration, leading to either an insecure or inaccessible device
if the lock on the candidate configuration does not also apply to the
<copy-config> operation when applied to it.</p>
<p>Configuration information is by its very nature sensitive.  Its
transmission in the clear and without integrity checking leaves
devices open to classic eavesdropping attacks.  Configuration
information often contains passwords, user names, service
descriptions, and topological information, all of which are
sensitive.  Because of this, this protocol should be implemented
carefully with adequate attention to all manner of attack one might
expect to experience with other management interfaces.</p>
<p>The protocol, therefore, must minimally support options for both
confidentiality and authentication.  It is anticipated that the
underlying protocol (SSH, BEEP, etc) will provide for both
confidentiality and authentication, as is required.  It is further
expected that the identity of each end of a NETCONF session will be
available to the other in order to determine authorization for any
given request.  One could also easily envision additional
information, such as transport and encryption methods, being made
available for purposes of authorization.  NETCONF itself provide no
means to re-authenticate, much less authenticate.  All such actions
occur at lower layers.</p>
<p>Enns                        Standards Track                    [Page 64]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>Different environments may well allow different rights prior to and
then after authentication.  Thus, an authorization model is not
specified in this document.  When an operation is not properly
authorized, a simple "access denied" is sufficient.  Note that
authorization information may be exchanged in the form of
configuration information, which is all the more reason to ensure the
security of the connection.</p>
<p>That having been said, it is important to recognize that some
operations are clearly more sensitive by nature than others.  For
instance, <copy-config> to the startup or running configurations is
clearly not a normal provisioning operation, whereas <edit-config>
is.  Such global operations MUST disallow the changing of information
that an individual does not have authorization to perform.  For
example, if a user A is not allowed to configure an IP address on an
interface but user B has configured an IP address on an interface in
the <candidate> configuration, user A must not be allowed to commit
the <candidate> configuration.</p>
<p>Similarly, just because someone says "go write a configuration
through the URL capability at a particular place", this does not mean
that an element should do it without proper authorization.</p>
<p>The <lock> operation will demonstrate that NETCONF is intended for
use by systems that have at least some trust of the administrator.
As specified in this document, it is possible to lock portions of a
configuration that a principal might not otherwise have access to.
After all, the entire configuration is locked.  To mitigate this
problem, there are two approaches.  It is possible to kill another
NETCONF session programmatically from within NETCONF if one knows the
session identifier of the offending session.  The other possible way
to break a lock is to provide an function within the device's native
user interface.  These two mechanisms suffer from a race condition
that may be ameliorated by removing the offending user from an AAA
server.  However, such a solution is not useful in all deployment
scenarios, such as those where SSH public/private key pairs are used.</p>
<p>Enns                        Standards Track                    [Page 65]

RFC 4741                    NETCONF Protocol               December 2006</p>
<ol start="10">
<li>IANA Considerations</li>
</ol>
<p>10.1.  NETCONF XML Namespace</p>
<p>This document registers a URI for the NETCONF XML namespace in the
IETF XML registry [7].</p>
<p>Following the format in RFC 3688, IANA has made the following
registration.</p>
<p>URI: urn:ietf:params:xml:ns:netconf:base:1.0</p>
<p>Registrant Contact: The IESG.</p>
<p>XML: N/A, the requested URI is an XML namespace.</p>
<p>10.2.  NETCONF XML Schema</p>
<p>This document registers a URI for the NETCONF XML schema in the IETF
XML registry [7].</p>
<p>Following the format in RFC 3688, IANA has made the following
registration.</p>
<p>URI: urn:ietf:params:xml:schema:netconf</p>
<p>Registrant Contact: The IESG.</p>
<p>XML: Appendix B of this document.</p>
<p>10.3.  NETCONF Capability URNs</p>
<p>This document creates a registry that allocates NETCONF capability
identifiers.  Additions to the registry require IETF Standards
Action.</p>
<p>The initial content of the registry contains the capability URNs
defined in Section 8.</p>
<p>Following the guidelines in RFC 3553 [6], IANA assigned a NETCONF
sub-namespace as follows:</p>
<p>Registry name: netconf</p>
<p>Specification: Section 8 of this document.</p>
<p>Repository: The following table.</p>
<p>Enns                        Standards Track                    [Page 66]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>+--------------------+----------------------------------------------+
| Index              | Capability Identifier                        |
+--------------------+----------------------------------------------+
| :writable-running  | urn:ietf:params:netconf:capability:writable- |
|                    | running:1.0                                  |
|                    |                                              |
| :candidate         | urn:ietf:params:netconf:capability:candidate |
|                    | :1.0                                         |
|                    |                                              |
| :confirmed-commit  | urn:ietf:params:netconf:capability:confirmed |
|                    | -commit:1.0                                  |
|                    |                                              |
| :rollback-on-error | urn:ietf:params:netconf:capability:rollback- |
|                    | on-error:1.0                                 |
|                    |                                              |
| :validate          | urn:ietf:params:netconf:capability:validate: |
|                    | 1.0                                          |
|                    |                                              |
| :startup           | urn:ietf:params:netconf:capability:startup:1 |
|                    | .0                                           |
|                    |                                              |
| :url               | urn:ietf:params:netconf:capability:url:1.0   |
|                    |                                              |
| :xpath             | urn:ietf:params:netconf:capability:xpath:1.0 |
+--------------------+----------------------------------------------+</p>
<p>Index value: The capability name.</p>
<p>Enns                        Standards Track                    [Page 67]

RFC 4741                    NETCONF Protocol               December 2006</p>
<ol start="11">
<li>Authors and Acknowledgements</li>
</ol>
<p>This document was written by:</p>
<pre><code>  Andy Bierman

  Ken Crozier, Cisco Systems

  Rob Enns, Juniper Networks

  Ted Goddard, IceSoft

  Eliot Lear, Cisco Systems

  Phil Shafer, Juniper Networks

  Steve Waldbusser

  Margaret Wasserman, ThingMagic
</code></pre>
<p>The authors would like to acknowledge the members of the NETCONF
working group.  In particular, we would like to thank Wes Hardaker
for his persistance and patience in assisting us with security
considerations.  We would also like to thank Randy Presuhn, Sharon
Chisholm, Juergen Schoenwalder, Glenn Waters, David Perkins, Weijing
Chen, Simon Leinen, Keith Allen, and Dave Harrington for all of their
valuable advice.</p>
<ol start="12">
<li>References</li>
</ol>
<p>12.1.  Normative References</p>
<p>[1]  Sperberg-McQueen, C., Paoli, J., Maler, E., and T. Bray,
"Extensible Markup Language (XML) 1.0 (Second Edition)", World
Wide Web Consortium, http://www.w3.org/TR/2000/REC-xml-20001006,
October 2000.</p>
<p>[2]  Clark, J. and S. DeRose, "XML Path Language (XPath) Version
1.0", World Wide Web Consortium Recommendation,
http://www.w3.org/TR/1999/REC-xpath-19991116, November 1999.</p>
<p>[3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.</p>
<p>[4]  Wasserman, M. and T. Goddard, "Using the NETCONF Configuration
Protocol over Secure SHell (SSH)", RFC 4742, December 2006.</p>
<p>Enns                        Standards Track                    [Page 68]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>[5]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.</p>
<p>[6]  Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF
URN Sub-namespace for Registered Protocol Parameters", BCP 73,
RFC 3553, June 2003.</p>
<p>[7]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.</p>
<p>12.2.  Informative References</p>
<p>[8]   Clark, J., "XSL Transformations (XSLT) Version 1.0", World Wide
Web Consortium Recommendation, http://www.w3.org/TR/1999/REC-
xslt-19991116, November 1999.</p>
<p>[9]   Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.</p>
<p>[10]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol
Architecture", RFC 4251, January 2006.</p>
<p>[11]  Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865,
June 2000.</p>
<p>[12]  Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the
Use of Extensible Markup Language (XML) within IETF Protocols",
BCP 70, RFC 3470, January 2003.</p>
<p>Enns                        Standards Track                    [Page 69]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>Appendix A.  NETCONF Error List</p>
<p>Tag:         in-use
Error-type:  protocol, application
Severity:    error
Error-info:  none
Description: The request requires a resource that already in use.</p>
<p>Tag:         invalid-value
Error-type:  protocol, application
Severity:    error
Error-info:  none
Description: The request specifies an unacceptable value for one
or more parameters.</p>
<p>Tag:         too-big
Error-type:  transport, rpc, protocol, application
Severity:    error
Error-info:  none
Description: The request or response (that would be generated) is too
large for the implementation to handle.</p>
<p>Tag:         missing-attribute
Error-type:  rpc, protocol, application
Severity:    error
Error-info:  <bad-attribute> : name of the missing attribute
<bad-element> : name of the element that should
contain the missing attribute
Description: An expected attribute is missing.</p>
<p>Tag:         bad-attribute
Error-type:  rpc, protocol, application
Severity:    error
Error-info:  <bad-attribute> : name of the attribute w/ bad value
<bad-element> : name of the element that contains
the attribute with the bad value
Description: An attribute value is not correct; e.g., wrong type,
out of range, pattern mismatch.</p>
<p>Tag:         unknown-attribute
Error-type:  rpc, protocol, application
Severity:    error
Error-info:  <bad-attribute> : name of the unexpected attribute
<bad-element> : name of the element that contains
the unexpected attribute
Description: An unexpected attribute is present.</p>
<p>Enns                        Standards Track                    [Page 70]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>Tag:         missing-element
Error-type:  rpc, protocol, application
Severity:    error
Error-info:  <bad-element> : name of the missing element
Description: An expected element is missing.</p>
<p>Tag:         bad-element
Error-type:  rpc, protocol, application
Severity:    error
Error-info:  <bad-element> : name of the element w/ bad value
Description: An element value is not correct; e.g., wrong type,
out of range, pattern mismatch.</p>
<p>Tag:         unknown-element
Error-type:  rpc, protocol, application
Severity:    error
Error-info:  <bad-element> : name of the unexpected element
Description: An unexpected element is present.</p>
<p>Tag:         unknown-namespace
Error-type:  rpc, protocol, application
Severity:    error
Error-info:  <bad-element> : name of the element that contains
the unexpected namespace
<bad-namespace> : name of the unexpected namespace
Description: An unexpected namespace is present.</p>
<p>Tag:         access-denied
Error-type:  rpc, protocol, application
Severity:    error
Error-info:  none
Description: Access to the requested RPC, protocol operation,
or data model is denied because authorization failed.</p>
<p>Tag:         lock-denied
Error-type:  protocol
Severity:    error
Error-info:  <session-id> : session ID of session holding the
requested lock, or zero to indicate a non-NETCONF
entity holds the lock
Description: Access to the requested lock is denied because the
lock is currently held by another entity.</p>
<p>Enns                        Standards Track                    [Page 71]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>Tag:         resource-denied
Error-type:  transport, rpc, protocol, application
Severity:    error
Error-info:  none
Description: Request could not be completed because of insufficient
resources.</p>
<p>Tag:         rollback-failed
Error-type:  protocol, application
Severity:    error
Error-info:  none
Description: Request to rollback some configuration change (via
rollback-on-error or discard-changes operations) was
not completed for some reason.</p>
<p>Tag:         data-exists
Error-type:  application
Severity:    error
Error-info:  none
Description: Request could not be completed because the relevant
data model content already exists. For example,
a 'create' operation was attempted on data that
already exists.</p>
<p>Tag:         data-missing
Error-type:  application
Severity:    error
Error-info:  none
Description: Request could not be completed because the relevant
data model content does not exist.  For example,
a 'replace' or 'delete' operation was attempted on
data that does not exist.</p>
<p>Tag:         operation-not-supported
Error-type:  rpc, protocol, application
Severity:    error
Error-info:  none
Description: Request could not be completed because the requested
operation is not supported by this implementation.</p>
<p>Tag:         operation-failed
Error-type:  rpc, protocol, application
Severity:    error
Error-info:  none
Description: Request could not be completed because the requested
operation failed for some reason not covered by
any other error condition.</p>
<p>Enns                        Standards Track                    [Page 72]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>Tag:         partial-operation
Error-type:  application
Severity:    error
Error-info:  <ok-element> : identifies an element in the data model
for which the requested operation has been completed
for that node and all its child nodes.  This element
can appear zero or more times in the <error-info>
container.</p>
<pre><code>            &lt;err-element&gt; : identifies an element in the data model
            for which the requested operation has failed for that
            node and all its child nodes.  This element
            can appear zero or more times in the &lt;error-info&gt;
            container.

            &lt;noop-element&gt; : identifies an element in the data model
            for which the requested operation was not attempted for
            that node and all its child nodes.  This element
            can appear zero or more times in the &lt;error-info&gt;
            container.
</code></pre>
<p>Description: Some part of the requested operation failed or was
not attempted for some reason.  Full cleanup has
not been performed (e.g., rollback not supported)
by the server.  The error-info container is used
to identify which portions of the application
data model content for which the requested operation
has succeeded (<ok-element>), failed (<bad-element>),
or not been attempted (<noop-element>).</p>
<p>Enns                        Standards Track                    [Page 73]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>Appendix B.  XML Schema for NETCONF RPC and Protocol Operations</p>
<p>BEGIN</p>
   <?xml version="1.0" encoding="UTF-8"?>
<p>&lt;xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
targetNamespace="urn:ietf:params:xml:ns:netconf:base:1.0"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
xml:lang="en"&gt;
<!--
       import standard XML definitions
       -->
&lt;xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"&gt;
<a href="xs:annotation">xs:annotation</a>
<a href="xs:documentation">xs:documentation</a>
This import accesses the xml: attribute groups for the
xml:lang as declared on the error-message element.
&lt;/xs:documentation&gt;
&lt;/xs:annotation&gt;
&lt;/xs:import&gt;
<!--
       message-id attribute
       -->
&lt;xs:simpleType name="messageIdType"&gt;
&lt;xs:restriction base="xs:string"&gt;
&lt;xs:maxLength value="4095"/&gt;
&lt;/xs:restriction&gt;
&lt;/xs:simpleType&gt;
<!--
       Types used for session-id
     -->
&lt;xs:simpleType name="SessionId"&gt;
&lt;xs:restriction base="xs:unsignedInt"&gt;
&lt;xs:minInclusive value="1"/&gt;
&lt;/xs:restriction&gt;
&lt;/xs:simpleType&gt;
&lt;xs:simpleType name="SessionIdOrZero"&gt;
&lt;xs:restriction base="xs:unsignedInt"/&gt;
&lt;/xs:simpleType&gt;
<!--
       <rpc> element
       -->
&lt;xs:complexType name="rpcType"&gt;
<a href="xs:sequence">xs:sequence</a>
&lt;xs:element ref="rpcOperation"/&gt;</p>
<p>Enns                        Standards Track                    [Page 74]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code>   &lt;/xs:sequence&gt;
   &lt;xs:attribute name="message-id" type="messageIdType"
     use="required"/&gt;
   &lt;!--
     Arbitrary attributes can be supplied with &lt;rpc&gt; element.
   --&gt;
   &lt;xs:anyAttribute processContents="lax"/&gt;
 &lt;/xs:complexType&gt;
 &lt;xs:element name="rpc" type="rpcType"/&gt;
 &lt;!--
   data types and elements used to construct rpc-errors
   --&gt;
 &lt;xs:simpleType name="ErrorType"&gt;
   &lt;xs:restriction base="xs:string"&gt;
     &lt;xs:enumeration value="transport"/&gt;
     &lt;xs:enumeration value="rpc"/&gt;
     &lt;xs:enumeration value="protocol"/&gt;
     &lt;xs:enumeration value="application"/&gt;
   &lt;/xs:restriction&gt;
 &lt;/xs:simpleType&gt;
 &lt;xs:simpleType name="ErrorTag"&gt;
   &lt;xs:restriction base="xs:string"&gt;
     &lt;xs:enumeration value="in-use"/&gt;
     &lt;xs:enumeration value="invalid-value"/&gt;
     &lt;xs:enumeration value="too-big"/&gt;
     &lt;xs:enumeration value="missing-attribute"/&gt;
     &lt;xs:enumeration value="bad-attribute"/&gt;
     &lt;xs:enumeration value="unknown-attribute"/&gt;
     &lt;xs:enumeration value="missing-element"/&gt;
     &lt;xs:enumeration value="bad-element"/&gt;
     &lt;xs:enumeration value="unknown-element"/&gt;
     &lt;xs:enumeration value="unknown-namespace"/&gt;
     &lt;xs:enumeration value="access-denied"/&gt;
     &lt;xs:enumeration value="lock-denied"/&gt;
     &lt;xs:enumeration value="resource-denied"/&gt;
     &lt;xs:enumeration value="rollback-failed"/&gt;
     &lt;xs:enumeration value="data-exists"/&gt;
     &lt;xs:enumeration value="data-missing"/&gt;
     &lt;xs:enumeration value="operation-not-supported"/&gt;
     &lt;xs:enumeration value="operation-failed"/&gt;
     &lt;xs:enumeration value="partial-operation"/&gt;
   &lt;/xs:restriction&gt;
 &lt;/xs:simpleType&gt;
 &lt;xs:simpleType name="ErrorSeverity"&gt;
   &lt;xs:restriction base="xs:string"&gt;
     &lt;xs:enumeration value="error"/&gt;
     &lt;xs:enumeration value="warning"/&gt;
   &lt;/xs:restriction&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 75]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code> &lt;/xs:simpleType&gt;
 &lt;xs:complexType name="errorInfoType"&gt;
   &lt;xs:sequence&gt;
     &lt;xs:choice&gt;
       &lt;xs:element name="session-id" type="SessionIdOrZero"/&gt;
       &lt;xs:sequence minOccurs="0" maxOccurs="unbounded"&gt;
         &lt;xs:sequence&gt;
           &lt;xs:element name="bad-attribute" type="xs:QName"
             minOccurs="0" maxOccurs="1"/&gt;
           &lt;xs:element name="bad-element" type="xs:QName"
             minOccurs="0" maxOccurs="1"/&gt;
           &lt;xs:element name="ok-element" type="xs:QName"
             minOccurs="0" maxOccurs="1"/&gt;
           &lt;xs:element name="err-element" type="xs:QName"
             minOccurs="0" maxOccurs="1"/&gt;
           &lt;xs:element name="noop-element" type="xs:QName"
             minOccurs="0" maxOccurs="1"/&gt;
           &lt;xs:element name="bad-namespace" type="xs:QName"
             minOccurs="0" maxOccurs="1"/&gt;
         &lt;/xs:sequence&gt;
       &lt;/xs:sequence&gt;
     &lt;/xs:choice&gt;
     &lt;!-- elements from any other namespace are also allowed
          to follow the NETCONF elements --&gt;
     &lt;xs:any namespace="##other"
       minOccurs="0" maxOccurs="unbounded"/&gt;
   &lt;/xs:sequence&gt;
 &lt;/xs:complexType&gt;
 &lt;xs:complexType name="rpcErrorType"&gt;
   &lt;xs:sequence&gt;
     &lt;xs:element name="error-type" type="ErrorType"/&gt;
     &lt;xs:element name="error-tag" type="ErrorTag"/&gt;
     &lt;xs:element name="error-severity" type="ErrorSeverity"/&gt;
     &lt;xs:element name="error-app-tag" type="xs:string"
                 minOccurs="0"/&gt;
     &lt;xs:element name="error-path" type="xs:string" minOccurs="0"/&gt;
     &lt;xs:element name="error-message" minOccurs="0"&gt;
       &lt;xs:complexType&gt;
         &lt;xs:simpleContent&gt;
           &lt;xs:extension base="xs:string"&gt;
             &lt;xs:attribute ref="xml:lang" use="optional"/&gt;
           &lt;/xs:extension&gt;
         &lt;/xs:simpleContent&gt;
       &lt;/xs:complexType&gt;
     &lt;/xs:element&gt;
     &lt;xs:element name="error-info" type="errorInfoType"
       minOccurs="0"/&gt;
   &lt;/xs:sequence&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 76]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code> &lt;/xs:complexType&gt;
 &lt;!--
   &lt;rpc-reply&gt; element
   --&gt;
 &lt;xs:complexType name="rpcReplyType"&gt;
   &lt;xs:choice&gt;
     &lt;xs:element name="ok"/&gt;
     &lt;xs:group ref="rpcResponse"/&gt;
   &lt;/xs:choice&gt;
   &lt;xs:attribute name="message-id" type="messageIdType"
     use="optional"/&gt;
   &lt;!--
     Any attributes supplied with &lt;rpc&gt; element must be returned
     on &lt;rpc-reply&gt;.
   --&gt;
   &lt;xs:anyAttribute processContents="lax"/&gt;
 &lt;/xs:complexType&gt;
 &lt;xs:group name="rpcResponse"&gt;
   &lt;xs:sequence&gt;
     &lt;xs:element name="rpc-error" type="rpcErrorType"
       minOccurs="0" maxOccurs="unbounded"/&gt;
     &lt;xs:element name="data" type="dataInlineType" minOccurs="0"/&gt;
   &lt;/xs:sequence&gt;
 &lt;/xs:group&gt;
 &lt;xs:element name="rpc-reply" type="rpcReplyType"/&gt;
 &lt;!--
   Type for &lt;test-option&gt; parameter to &lt;edit-config&gt;
   --&gt;
 &lt;xs:simpleType name="testOptionType"&gt;
   &lt;xs:restriction base="xs:string"&gt;
     &lt;xs:enumeration value="test-then-set"/&gt;
     &lt;xs:enumeration value="set"/&gt;
   &lt;/xs:restriction&gt;
 &lt;/xs:simpleType&gt;
 &lt;!--
   Type for &lt;error-option&gt; parameter to &lt;edit-config&gt;
   --&gt;
 &lt;xs:simpleType name="errorOptionType"&gt;
   &lt;xs:restriction base="xs:string"&gt;
     &lt;xs:annotation&gt;
       &lt;xs:documentation&gt;
         Use of the rollback-on-error value requires
         the :rollback-on-error capability.
       &lt;/xs:documentation&gt;
     &lt;/xs:annotation&gt;
     &lt;xs:enumeration value="stop-on-error"/&gt;
     &lt;xs:enumeration value="continue-on-error"/&gt;
     &lt;xs:enumeration value="rollback-on-error"/&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 77]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code>   &lt;/xs:restriction&gt;
 &lt;/xs:simpleType&gt;
 &lt;!--
   rpcOperationType: used as a base type for all
   NETCONF operations
   --&gt;
 &lt;xs:complexType name="rpcOperationType"/&gt;
 &lt;xs:element name="rpcOperation"
             type="rpcOperationType" abstract="true"/&gt;
 &lt;!--
   Type for &lt;config&gt; element
   --&gt;
 &lt;xs:complexType name="configInlineType"&gt;
   &lt;xs:complexContent&gt;
     &lt;xs:extension base="xs:anyType"/&gt;
   &lt;/xs:complexContent&gt;
 &lt;/xs:complexType&gt;
 &lt;!--
   Type for &lt;data&gt; element
   --&gt;
 &lt;xs:complexType name="dataInlineType"&gt;
   &lt;xs:complexContent&gt;
     &lt;xs:extension base="xs:anyType"/&gt;
   &lt;/xs:complexContent&gt;
 &lt;/xs:complexType&gt;
 &lt;!--
   Type for &lt;filter&gt; element
   --&gt;
 &lt;xs:simpleType name="FilterType"&gt;
   &lt;xs:restriction base="xs:string"&gt;
     &lt;xs:annotation&gt;
       &lt;xs:documentation&gt;
         Use of the xpath value requires the :xpath capability.
      &lt;/xs:documentation&gt;
     &lt;/xs:annotation&gt;
     &lt;xs:enumeration value="subtree"/&gt;
     &lt;xs:enumeration value="xpath"/&gt;
   &lt;/xs:restriction&gt;
 &lt;/xs:simpleType&gt;
 &lt;xs:complexType name="filterInlineType"&gt;
   &lt;xs:complexContent&gt;
     &lt;xs:extension base="xs:anyType"&gt;
       &lt;xs:attribute name="type"
                     type="FilterType" default="subtree"/&gt;
       &lt;!-- if type="xpath", the xpath expression
       appears in the select element --&gt;
       &lt;xs:attribute name="select"/&gt;
     &lt;/xs:extension&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 78]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code>   &lt;/xs:complexContent&gt;
 &lt;/xs:complexType&gt;
 &lt;!--
   configuration datastore names
   --&gt;
 &lt;xs:annotation&gt;
   &lt;xs:documentation&gt;
     The startup datastore can be used only if the :startup
     capability is advertised.  The candidate datastore can
     be used only if the :candidate datastore is advertised.
    &lt;/xs:documentation&gt;
 &lt;/xs:annotation&gt;
 &lt;xs:complexType name="configNameType"/&gt;
 &lt;xs:element name="config-name"
             type="configNameType" abstract="true"/&gt;
 &lt;xs:element name="startup" type="configNameType"
             substitutionGroup="config-name"/&gt;
 &lt;xs:element name="candidate" type="configNameType"
             substitutionGroup="config-name"/&gt;
 &lt;xs:element name="running" type="configNameType"
             substitutionGroup="config-name"/&gt;
 &lt;!--
   operation attribute used in &lt;edit-config&gt;
   --&gt;
 &lt;xs:simpleType name="editOperationType"&gt;
   &lt;xs:restriction base="xs:string"&gt;
     &lt;xs:enumeration value="merge"/&gt;
     &lt;xs:enumeration value="replace"/&gt;
     &lt;xs:enumeration value="create"/&gt;
     &lt;xs:enumeration value="delete"/&gt;
   &lt;/xs:restriction&gt;
 &lt;/xs:simpleType&gt;
 &lt;xs:attribute name="operation"
               type="editOperationType" default="merge"/&gt;
 &lt;!--
   &lt;default-operation&gt; element
   --&gt;
 &lt;xs:simpleType name="defaultOperationType"&gt;
   &lt;xs:restriction base="xs:string"&gt;
     &lt;xs:enumeration value="merge"/&gt;
     &lt;xs:enumeration value="replace"/&gt;
     &lt;xs:enumeration value="none"/&gt;
   &lt;/xs:restriction&gt;
 &lt;/xs:simpleType&gt;
 &lt;!--
   &lt;url&gt; element
   --&gt;
 &lt;xs:complexType name="configURIType"&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 79]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code>   &lt;xs:annotation&gt;
     &lt;xs:documentation&gt;
       Use of the url element requires the :url capability.
     &lt;/xs:documentation&gt;
   &lt;/xs:annotation&gt;
   &lt;xs:simpleContent&gt;
     &lt;xs:extension base="xs:anyURI"/&gt;
   &lt;/xs:simpleContent&gt;
 &lt;/xs:complexType&gt;
 &lt;!--
   Type for &lt;source&gt; element (except &lt;get-config&gt;)
   --&gt;
 &lt;xs:complexType name="rpcOperationSourceType"&gt;
   &lt;xs:choice&gt;
     &lt;xs:element name="config" type="configInlineType"/&gt;
     &lt;xs:element ref="config-name"/&gt;
     &lt;xs:element name="url" type="configURIType"/&gt;
   &lt;/xs:choice&gt;
 &lt;/xs:complexType&gt;
 &lt;!--
   Type for &lt;source&gt; element in &lt;get-config&gt;
   --&gt;
 &lt;xs:complexType name="getConfigSourceType"&gt;
   &lt;xs:choice&gt;
     &lt;xs:element ref="config-name"/&gt;
     &lt;xs:element name="url" type="configURIType"/&gt;
   &lt;/xs:choice&gt;
 &lt;/xs:complexType&gt;
 &lt;!--
   Type for &lt;target&gt; element
   --&gt;
 &lt;xs:complexType name="rpcOperationTargetType"&gt;
   &lt;xs:choice&gt;
     &lt;xs:element ref="config-name"/&gt;
     &lt;xs:element name="url" type="configURIType"/&gt;
   &lt;/xs:choice&gt;
 &lt;/xs:complexType&gt;
 &lt;!--
   &lt;get-config&gt; operation
   --&gt;
 &lt;xs:complexType name="getConfigType"&gt;
   &lt;xs:complexContent&gt;
     &lt;xs:extension base="rpcOperationType"&gt;
       &lt;xs:sequence&gt;
         &lt;xs:element name="source"
                     type="getConfigSourceType"/&gt;
         &lt;xs:element name="filter"
                     type="filterInlineType" minOccurs="0"/&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 80]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code>       &lt;/xs:sequence&gt;
     &lt;/xs:extension&gt;
   &lt;/xs:complexContent&gt;
 &lt;/xs:complexType&gt;
 &lt;xs:element name="get-config" type="getConfigType"
             substitutionGroup="rpcOperation"/&gt;
 &lt;!--
   &lt;edit-config&gt; operation
   --&gt;
 &lt;xs:complexType name="editConfigType"&gt;
   &lt;xs:complexContent&gt;
     &lt;xs:extension base="rpcOperationType"&gt;
       &lt;xs:sequence&gt;
         &lt;xs:annotation&gt;
           &lt;xs:documentation&gt;
             Use of the test-option element requires the
             :validate capability.  Use of the url element
             requires the :url capability.
           &lt;/xs:documentation&gt;
         &lt;/xs:annotation&gt;
         &lt;xs:element name="target"
                     type="rpcOperationTargetType"/&gt;
         &lt;xs:element name="default-operation"
                     type="defaultOperationType"
                     minOccurs="0"/&gt;
         &lt;xs:element name="test-option"
                     type="testOptionType"
                     minOccurs="0"/&gt;
         &lt;xs:element name="error-option"
                     type="errorOptionType"
                     minOccurs="0"/&gt;
         &lt;xs:choice&gt;
           &lt;xs:element name="config"
                       type="configInlineType"/&gt;
           &lt;xs:element name="url"
                       type="configURIType"/&gt;
         &lt;/xs:choice&gt;
       &lt;/xs:sequence&gt;
     &lt;/xs:extension&gt;
   &lt;/xs:complexContent&gt;
 &lt;/xs:complexType&gt;
 &lt;xs:element name="edit-config" type="editConfigType"
             substitutionGroup="rpcOperation"/&gt;
 &lt;!--
   &lt;copy-config&gt; operation
   --&gt;
 &lt;xs:complexType name="copyConfigType"&gt;
   &lt;xs:complexContent&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 81]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code>     &lt;xs:extension base="rpcOperationType"&gt;
       &lt;xs:sequence&gt;
         &lt;xs:element name="target" type="rpcOperationTargetType"/&gt;
         &lt;xs:element name="source" type="rpcOperationSourceType"/&gt;
       &lt;/xs:sequence&gt;
     &lt;/xs:extension&gt;
   &lt;/xs:complexContent&gt;
 &lt;/xs:complexType&gt;
 &lt;xs:element name="copy-config" type="copyConfigType"
             substitutionGroup="rpcOperation"/&gt;
 &lt;!--
   &lt;delete-config&gt; operation
   --&gt;
 &lt;xs:complexType name="deleteConfigType"&gt;
   &lt;xs:complexContent&gt;
     &lt;xs:extension base="rpcOperationType"&gt;
       &lt;xs:sequence&gt;
         &lt;xs:element name="target" type="rpcOperationTargetType"/&gt;
       &lt;/xs:sequence&gt;
     &lt;/xs:extension&gt;
   &lt;/xs:complexContent&gt;
 &lt;/xs:complexType&gt;
 &lt;xs:element name="delete-config" type="deleteConfigType"
             substitutionGroup="rpcOperation"/&gt;
 &lt;!--
   &lt;get&gt; operation
   --&gt;
 &lt;xs:complexType name="getType"&gt;
   &lt;xs:complexContent&gt;
     &lt;xs:extension base="rpcOperationType"&gt;
       &lt;xs:sequence&gt;
         &lt;xs:element name="filter"
                     type="filterInlineType" minOccurs="0"/&gt;
       &lt;/xs:sequence&gt;
     &lt;/xs:extension&gt;
   &lt;/xs:complexContent&gt;
 &lt;/xs:complexType&gt;
 &lt;xs:element name="get" type="getType"
             substitutionGroup="rpcOperation"/&gt;
 &lt;!--
   &lt;lock&gt; operation
   --&gt;
 &lt;xs:complexType name="lockType"&gt;
   &lt;xs:complexContent&gt;
     &lt;xs:extension base="rpcOperationType"&gt;
       &lt;xs:sequence&gt;
         &lt;xs:element name="target"
                     type="rpcOperationTargetType"/&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 82]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code>       &lt;/xs:sequence&gt;
     &lt;/xs:extension&gt;
   &lt;/xs:complexContent&gt;
 &lt;/xs:complexType&gt;
 &lt;xs:element name="lock" type="lockType"
             substitutionGroup="rpcOperation"/&gt;
 &lt;!--
   &lt;unlock&gt; operation
   --&gt;
 &lt;xs:complexType name="unlockType"&gt;
   &lt;xs:complexContent&gt;
     &lt;xs:extension base="rpcOperationType"&gt;
       &lt;xs:sequence&gt;
         &lt;xs:element name="target" type="rpcOperationTargetType"/&gt;
       &lt;/xs:sequence&gt;
     &lt;/xs:extension&gt;
   &lt;/xs:complexContent&gt;
 &lt;/xs:complexType&gt;
 &lt;xs:element name="unlock" type="unlockType"
             substitutionGroup="rpcOperation"/&gt;
 &lt;!--
   &lt;validate&gt; operation
   --&gt;
 &lt;xs:complexType name="validateType"&gt;
   &lt;xs:annotation&gt;
     &lt;xs:documentation&gt;
       The validate operation requires the :validate capability.
     &lt;/xs:documentation&gt;
   &lt;/xs:annotation&gt;
   &lt;xs:complexContent&gt;
     &lt;xs:extension base="rpcOperationType"&gt;
       &lt;xs:sequence&gt;
         &lt;xs:element name="source" type="rpcOperationSourceType"/&gt;
       &lt;/xs:sequence&gt;
     &lt;/xs:extension&gt;
   &lt;/xs:complexContent&gt;
 &lt;/xs:complexType&gt;
 &lt;xs:element name="validate" type="validateType"
             substitutionGroup="rpcOperation"/&gt;
 &lt;!--
   &lt;commit&gt; operation
   --&gt;
 &lt;xs:simpleType name="confirmTimeoutType"&gt;
   &lt;xs:restriction base="xs:unsignedInt"&gt;
     &lt;xs:minInclusive value="1"/&gt;
   &lt;/xs:restriction&gt;
 &lt;/xs:simpleType&gt;
 &lt;xs:complexType name="commitType"&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 83]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code>   &lt;xs:annotation&gt;
     &lt;xs:documentation&gt;
       The commit operation requires the :candidate capability.
     &lt;/xs:documentation&gt;
   &lt;/xs:annotation&gt;
   &lt;xs:complexContent&gt;
     &lt;xs:extension base="rpcOperationType"&gt;
       &lt;xs:sequence&gt;
         &lt;xs:annotation&gt;
           &lt;xs:documentation&gt;
             Use of the confirmed and confirm-timeout elements
             requires the :confirmed-commit capability.
           &lt;/xs:documentation&gt;
         &lt;/xs:annotation&gt;
         &lt;xs:element name="confirmed" minOccurs="0"/&gt;
         &lt;xs:element name="confirm-timeout"
                     type="confirmTimeoutType"
                     minOccurs="0"/&gt;
       &lt;/xs:sequence&gt;
     &lt;/xs:extension&gt;
   &lt;/xs:complexContent&gt;
 &lt;/xs:complexType&gt;
 &lt;xs:element name="commit" type="commitType"
             substitutionGroup="rpcOperation"/&gt;
 &lt;!--
   &lt;discard-changes&gt; operation
   --&gt;
 &lt;xs:complexType name="discardChangesType"&gt;
   &lt;xs:annotation&gt;
     &lt;xs:documentation&gt;
       The discard-changes operation requires the
       :candidate capability.
     &lt;/xs:documentation&gt;
   &lt;/xs:annotation&gt;
   &lt;xs:complexContent&gt;
     &lt;xs:extension base="rpcOperationType"/&gt;
   &lt;/xs:complexContent&gt;
 &lt;/xs:complexType&gt;
 &lt;xs:element name="discard-changes"
             type="discardChangesType"
             substitutionGroup="rpcOperation"/&gt;
 &lt;!--
   &lt;close-session&gt; operation
   --&gt;
 &lt;xs:complexType name="closeSessionType"&gt;
   &lt;xs:complexContent&gt;
     &lt;xs:extension base="rpcOperationType"/&gt;
   &lt;/xs:complexContent&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 84]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code> &lt;/xs:complexType&gt;
 &lt;xs:element name="close-session" type="closeSessionType"
             substitutionGroup="rpcOperation"/&gt;
 &lt;!--
   &lt;kill-session&gt; operation
   --&gt;
 &lt;xs:complexType name="killSessionType"&gt;
   &lt;xs:complexContent&gt;
     &lt;xs:extension base="rpcOperationType"&gt;
       &lt;xs:sequence&gt;
         &lt;xs:element name="session-id"
                     type="SessionId" minOccurs="1"/&gt;
       &lt;/xs:sequence&gt;
     &lt;/xs:extension&gt;
   &lt;/xs:complexContent&gt;
 &lt;/xs:complexType&gt;
 &lt;xs:element name="kill-session" type="killSessionType"
             substitutionGroup="rpcOperation"/&gt;
 &lt;!--
   &lt;hello&gt; element
   --&gt;
 &lt;xs:element name="hello"&gt;
   &lt;xs:complexType&gt;
     &lt;xs:sequence&gt;
       &lt;xs:element name="capabilities"&gt;
         &lt;xs:complexType&gt;
           &lt;xs:sequence&gt;
             &lt;xs:element name="capability" type="xs:anyURI"
               maxOccurs="unbounded"/&gt;
           &lt;/xs:sequence&gt;
         &lt;/xs:complexType&gt;
       &lt;/xs:element&gt;
       &lt;xs:element name="session-id"
                   type="SessionId" minOccurs="0"/&gt;
     &lt;/xs:sequence&gt;
   &lt;/xs:complexType&gt;
 &lt;/xs:element&gt;
</code></pre>
<p>&lt;/xs:schema&gt;</p>
<p>END</p>
<p>Enns                        Standards Track                    [Page 85]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>Appendix C.  Capability Template</p>
<p>C.1.  capability-name (template)</p>
<p>C.1.1.  Overview</p>
<p>C.1.2.  Dependencies</p>
<p>C.1.3.  Capability Identifier</p>
<p>The {name} capability is identified by the following capability
string:</p>
<pre><code>  {capability uri}
</code></pre>
<p>C.1.4.  New Operations</p>
<p>C.1.4.1.  <op-name></p>
<p>C.1.5.  Modifications to Existing Operations</p>
<p>C.1.5.1.  <op-name></p>
<p>If existing operations are not modified by this capability, this
section may be omitted.</p>
<p>C.1.6.  Interactions with Other Capabilities</p>
<p>If this capability does not interact with other capabilities, this
section may be omitted.</p>
<p>Enns                        Standards Track                    [Page 86]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>Appendix D.  Configuring Multiple Devices with NETCONF</p>
<p>D.1.  Operations on Individual Devices</p>
<p>Consider the work involved in performing a configuration update
against a single individual device.  In making a change to the
configuration, the application needs to build trust that its change
has been made correctly and that it has not impacted the operation of
the device.  The application (and the application user) should feel
confident that their change has not damaged the network.</p>
<p>Protecting each individual device consists of a number of steps:</p>
<p>o  Acquiring the configuration lock.</p>
<p>o  Loading the update.</p>
<p>o  Validating the incoming configuration.</p>
<p>o  Checkpointing the running configuration.</p>
<p>o  Changing the running configuration.</p>
<p>o  Testing the new configuration.</p>
<p>o  Making the change permanent (if desired).</p>
<p>o  Releasing the configuration lock.</p>
<p>Let's look at the details of each step.</p>
<p>D.1.1.  Acquiring the Configuration Lock</p>
<p>A lock should be acquired to prevent simultaneous updates from
multiple sources.  If multiple sources are affecting the device, the
application is hampered in both testing of its change to the
configuration and in recovery should the update fail.  Acquiring a
short-lived lock is a simple defense to prevent other parties from
introducing unrelated changes.</p>
<p>The lock can be acquired using the <lock> operation.</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;lock&gt;
     &lt;target&gt;
       &lt;running/&gt;
     &lt;/target&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 87]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code>   &lt;/lock&gt;
 &lt;/rpc&gt;
</code></pre>
<p>D.1.2.  Loading the Update</p>
<p>The configuration can be loaded onto the device without impacting the
running system.  If the :url capability is supported and lists "file"
as a supported scheme, incoming changes can be placed in a local
file.</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;copy-config&gt;
     &lt;target&gt;
       &lt;url&gt;file://incoming.conf&lt;/url&gt;
     &lt;/target&gt;
     &lt;source&gt;
       &lt;config&gt;
         &lt;!-- place incoming configuration here --&gt;
       &lt;/config&gt;
     &lt;/source&gt;
   &lt;/copy-config&gt;
 &lt;/rpc&gt;
</code></pre>
<p>If the :candidate capability is supported, the candidate
configuration can be used.</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;edit-config&gt;
     &lt;target&gt;
       &lt;candidate/&gt;
     &lt;/target&gt;
     &lt;config&gt;
       &lt;!-- place incoming configuration here --&gt;
     &lt;/config&gt;
   &lt;/edit-config&gt;
 &lt;/rpc&gt;
</code></pre>
<p>If the update fails, the user file can be deleted using the
<delete-config> operation, or the candidate configuration can be
reverted using the <discard-changes> operation.</p>
<p>Enns                        Standards Track                    [Page 88]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>D.1.3.  Validating the Incoming Configuration</p>
<p>Before the incoming configuration is applied, validating it is often
useful.  Validation allows the application to gain confidence that
the change will succeed and simplifies recovery if it does not.</p>
<p>If the device supports the :url capability and lists "file" as a
supported scheme, use the <validate> operation with the <source>
parameter set to the proper user file:</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;validate&gt;
     &lt;source&gt;
       &lt;url&gt;file://incoming.conf&lt;/url&gt;
     &lt;/source&gt;
   &lt;/validate&gt;
 &lt;/rpc&gt;
</code></pre>
<p>If the device supports the :candidate capability, some validation
will be performed as part of loading the incoming configuration into
the candidate.  For full validation, either pass the <validate>
parameter during the <edit-config> step given above, or use the
<validate> operation with the <source> parameter set to <candidate>.</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;validate&gt;
     &lt;source&gt;
       &lt;candidate/&gt;
     &lt;/source&gt;
   &lt;/validate&gt;
 &lt;/rpc&gt;
</code></pre>
<p>D.1.4.  Checkpointing the Running Configuration</p>
<p>The running configuration can be saved into a local file as a
checkpoint before loading the new configuration.  If the update
fails, the configuration can be restored by reloading the checkpoint
file.</p>
<p>The checkpoint file can be created using the <copy-config> operation.</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;copy-config&gt;
     &lt;target&gt;
       &lt;url&gt;file://checkpoint.conf&lt;/url&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 89]

RFC 4741                    NETCONF Protocol               December 2006</p>
<pre><code>     &lt;/target&gt;
     &lt;source&gt;
       &lt;running/&gt;
     &lt;/source&gt;
   &lt;/copy-config&gt;
 &lt;/rpc&gt;
</code></pre>
<p>To restore the checkpoint file, reverse the source and target
parameters.</p>
<p>D.1.5.  Changing the Running Configuration</p>
<p>When the incoming configuration has been safely loaded onto the
device and validated, it is ready to impact the running system.</p>
<p>If the device supports the :url capability and lists "file" as a
supported scheme, use the <edit-config> operation to merge the
incoming configuration into the running configuration.</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;edit-config&gt;
     &lt;target&gt;
       &lt;running/&gt;
     &lt;/target&gt;
     &lt;config&gt;
       &lt;url&gt;file://incoming.conf&lt;/url&gt;
     &lt;/config&gt;
   &lt;/edit-config&gt;
 &lt;/rpc&gt;
</code></pre>
<p>If the device supports the :candidate capability, use the <commit>
operation to set the running configuration to the candidate
configuration.  Use the <confirmed> parameter to allow automatic
reversion to the original configuration if connectivity to the device
fails.</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;commit&gt;
     &lt;confirmed/&gt;
     &lt;confirm-timeout&gt;120&lt;/confirm-timeout&gt;
   &lt;/commit&gt;
 &lt;/rpc&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 90]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>D.1.6.  Testing the New Configuration</p>
<p>Now that the incoming configuration has been integrated into the
running configuration, the application needs to gain trust that the
change has affected the device in the way intended without affecting
it negatively.</p>
<p>To gain this confidence, the application can run tests of the
operational state of the device.  The nature of the test is dependent
on the nature of the change and is outside the scope of this
document.  Such tests may include reachability from the system
running the application (using ping), changes in reachability to the
rest of the network (by comparing the device's routing table), or
inspection of the particular change (looking for operational evidence
of the BGP peer that was just added).</p>
<p>D.1.7.  Making the Change Permanent</p>
<p>When the configuration change is in place and the application has
sufficient faith in the proper function of this change, the
application should make the change permanent.</p>
<p>If the device supports the :startup capability, the current
configuration can be saved to the startup configuration by using the
startup configuration as the target of the <copy-config> operation.</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;copy-config&gt;
     &lt;target&gt;
       &lt;startup/&gt;
     &lt;/target&gt;
     &lt;source&gt;
       &lt;running/&gt;
     &lt;/source&gt;
   &lt;/copy-config&gt;
 &lt;/rpc&gt;
</code></pre>
<p>If the device supports the :candidate capability and a confirmed
commit was requested, the confirming commit must be sent before the
timeout expires.</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;commit/&gt;
 &lt;/rpc&gt;
</code></pre>
<p>Enns                        Standards Track                    [Page 91]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>D.1.8.  Releasing the Configuration Lock</p>
<p>When the configuration update is complete, the lock must be released,
allowing other applications access to the configuration.</p>
<p>Use the <unlock> operation to release the configuration lock.</p>
<pre><code> &lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
   &lt;unlock&gt;
     &lt;target&gt;
       &lt;running/&gt;
     &lt;/target&gt;
   &lt;/unlock&gt;
 &lt;/rpc&gt;
</code></pre>
<p>D.2.  Operations on Multiple Devices</p>
<p>When a configuration change requires updates across a number of
devices, care should be taken to provide the required transaction
semantics.  The NETCONF protocol contains sufficient primitives upon
which transaction-oriented operations can be built.  Providing
complete transactional semantics across multiple devices is
prohibitively expensive, but the size and number of windows for
failure scenarios can be reduced.</p>
<p>There are two classes of multi-device operations.  The first class
allows the operation to fail on individual devices without requiring
all devices to revert to their original state.  The operation can be
retried at a later time, or its failure simply reported to the user.
An example of this class might be adding an NTP server.  For this
class of operations, failure avoidance and recovery are focused on
the individual device.  This means recovery of the device, reporting
the failure, and perhaps scheduling another attempt.</p>
<p>The second class is more interesting, requiring that the operation
should complete on all devices or be fully reversed.  The network
should either be transformed into a new state or be reset to its
original state.  For example, a change to a VPN may require updates
to a number of devices.  Another example of this might be adding a
class-of-service definition.  Leaving the network in a state where
only a portion of the devices have been updated with the new
definition will lead to future failures when the definition is
referenced.</p>
<p>To give transactional semantics, the same steps used in single device
operations listed above are used, but are performed in parallel
across all devices.  Configuration locks should be acquired on all</p>
<p>Enns                        Standards Track                    [Page 92]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>target devices and kept until all devices are updated and the changes
made permanent.  Configuration changes should be uploaded and
validation performed across all devices.  Checkpoints should be made
on each device.  Then the running configuration can be changed,
tested, and made permanent.  If any of these steps fail, the previous
configurations can be restored on any devices upon which they were
changed.  After the changes have been completely implemented or
completely discarded, the locks on each device can be released.</p>
<p>Appendix E.  Deferred Features</p>
<p>The following features have been deferred until a future revision of
this document.</p>
<p>o  Granular locking of configuration objects.</p>
<p>o  Named configuration files/datastores.</p>
<p>o  Support for multiple NETCONF channels.</p>
<p>o  Asynchronous notifications.</p>
<p>o  Explicit protocol support for rollback of configuration changes to
prior versions.</p>
<p>Enns                        Standards Track                    [Page 93]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>Editor's Address</p>
<p>Rob Enns
Juniper Networks
1194 North Mathilda Ave
Sunnyvale, CA  94089
US</p>
<p>EMail: rpe@juniper.net</p>
<p>Enns                        Standards Track                    [Page 94]

RFC 4741                    NETCONF Protocol               December 2006</p>
<p>Full Copyright Statement</p>
<p>Copyright (C) The IETF Trust (2006).</p>
<p>This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.</p>
<p>This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.</p>
<p>Intellectual Property</p>
<p>The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights.  Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.</p>
<p>Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.</p>
<p>The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard.  Please address the information to the IETF at
ietf-ipr@ietf.org.</p>
<p>Acknowledgement</p>
<p>Funding for the RFC Editor function is currently provided by the
Internet Society.</p>
<p>Enns                        Standards Track                    [Page 95]
</p>

                    </main>

                    <nav class="nav-wrapper" aria-label="Page navigation">
                        <!-- Mobile navigation buttons -->


                        <div style="clear: both"></div>
                    </nav>
                </div>
            </div>

            <nav class="nav-wide-wrapper" aria-label="Page navigation">

            </nav>

        </div>

        <!-- Livereload script (if served using the cli tool) -->
        <script>
            const wsProtocol = location.protocol === 'https:' ? 'wss:' : 'ws:';
            const wsAddress = wsProtocol + "//" + location.host + "/" + "__livereload";
            const socket = new WebSocket(wsAddress);
            socket.onmessage = function (event) {
                if (event.data === "reload") {
                    socket.close();
                    location.reload();
                }
            };

            window.onbeforeunload = function() {
                socket.close();
            }
        </script>



        <script>
            window.playground_copyable = true;
        </script>


        <script src="elasticlunr.min.js"></script>
        <script src="mark.min.js"></script>
        <script src="searcher.js"></script>

        <script src="clipboard.min.js"></script>
        <script src="highlight.js"></script>
        <script src="book.js"></script>

        <!-- Custom JS scripts -->

        <script>
        window.addEventListener('load', function() {
            window.setTimeout(window.print, 100);
        });
        </script>

    </div>
    </body>
</html>
